From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Proposed util-linux split
Date: Tue, 26 Feb 2013 19:33:30 +0100 [thread overview]
Message-ID: <20130226193330.04f77759@skate> (raw)
In-Reply-To: <512C941A.1070207@zacarias.com.ar>
Dear Gustavo Zacarias,
On Tue, 26 Feb 2013 07:53:14 -0300, Gustavo Zacarias wrote:
> The last couple of days i've been thinking and working towards a
> solution that would split out libblkid/libuuid out of the util-linux
> package.
> It's a remake of my previous "util-linux don't install binaries" patch.
> The objectives are:
>
> * Upgrading to newer versions of the libraries - it's not required by
> any package, but it's useful for libblkid to recognize newer superblock
> types.
>
> * We can't upgrade util-linux past 2.20.1 unless we want to drop the
> basic loginutils functionality since it requires PAM starting from 2.21.
> By splitting the libraries out i can use just the libraries from newer
> util-linux versions. Caveat is you won't get the newer libraries if
> you're installing util-linux with the library options on.
I would suggest that we upgrade util-linux and add the necessary PAM
dependency when needed. We already have package/linux-pam/, so it
shouldn't be a big effort.
Of course, only the util-linux programs that actually need PAM support
should make this library become a dependency of util-linux.
> * Reduce bloat! The most important point for me, one packages needs
> libuuid and we get a dozen util-linux binaries around as a free gift.
>
> I've got a working not-quite-ready (needs cleanup) patchset that adds
> the libblkid and libuuid packages. These are based on a slightly patched
> (configure.ac & Makefile.am) util-linux-2.22.2 that basically reduces
> build time and keeps the original install target (you can't make -C
> libblkid install with newer util-linux versions, see
> http://karelzak.blogspot.com/2013/02/non-recursive-automake.html)
>
> When a package needs libuuid it would now change to:
> select BR2_PACKAGE_LIBUUID if !BR2_PACKAGE_UTIL_LINUX_LIBUUID
> to avoid duplication.
> And on libuuid Config.in:
> depends on !BR2_PACKAGE_UTIL_LINUX_LIBUUID
Would it be possible instead that util-linux always uses the libuuid
from the libuuid package?
> This lets us keep util-linux around (which doesn't work with external
> libblkid/libuuid because it doesn't expect them to be so) and slimmer
> versions of the libraries when people don't want util-linux.
>
> Another added bonus is libuuid doesn't require wchar this way.
>
> What do you think?
I must admit I don't really like having multiple packages for the same
upstream tarball. Another option is to make something like:
config BR2_PACKAGE_UTIL_LINUX
bool "util-linux"
select BR2_PACKAGE_UTIL_LINUX_LIBUUID if !BR2_PACKAGE_UTIL_LINUX_AT_LEAST_SOMETHING
config BR2_PACKAGE_UTIL_LINUX_AT_LEAST_SOMETHING
bool
config BR2_PACKAGE_UTIL_LINUX_LIBUUID
bool "libuuid"
config BR2_PACKAGE_UTIL_LINUX_LIBBLKDID
bool "libblkid"
select BR2_PACKAGE_UTIL_LINUX_AT_LEAST_SOMETHING
config BR2_PACKAGE_UTIL_LINUX_LIBMOUNT
bool "libmount"
select BR2_PACKAGE_UTIL_LINUX_AT_LEAST_SOMETHING
config BR2_PACKAGE_UTIL_LINUX_SOMEPROGA
bool "program a"
select BR2_PACKAGE_UTIL_LINUX_AT_LEAST_SOMETHING
This way, by default util-linux only installs libuuid.
No?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-02-26 18:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-26 10:53 [Buildroot] Proposed util-linux split Gustavo Zacarias
2013-02-26 18:33 ` Thomas Petazzoni [this message]
2013-02-26 18:40 ` Thomas Petazzoni
2013-02-26 18:49 ` Gustavo Zacarias
2013-02-26 18:41 ` Gustavo Zacarias
2013-02-26 19:03 ` Thomas Petazzoni
2013-02-26 19:07 ` Gustavo Zacarias
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130226193330.04f77759@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox