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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.