Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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