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