All of 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 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.