Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] Proposed util-linux split
Date: Tue, 26 Feb 2013 07:53:14 -0300	[thread overview]
Message-ID: <512C941A.1070207@zacarias.com.ar> (raw)


Hi all.
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.

* 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

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?
Regards.

             reply	other threads:[~2013-02-26 10:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26 10:53 Gustavo Zacarias [this message]
2013-02-26 18:33 ` [Buildroot] Proposed util-linux split Thomas Petazzoni
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=512C941A.1070207@zacarias.com.ar \
    --to=gustavo@zacarias.com.ar \
    --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