Bug#614708: libc6 could just Recommends libc-bin
On Wed, Feb 23, 2011 at 08:56:01PM +0100, Aurelien Jarno wrote:
> On Tue, Feb 22, 2011 at 04:03:18PM -0800, Josh Triplett wrote:
> > Package: libc6
> > Version: 2.11.2-11
> > Severity: wishlist
> >
> > Looking carefully at the contents of libc-bin, it appears that libc6
> > could just Recommends libc-bin, rather than having a Depends on it.
> > Specifically, taking the contents of libc-bin piece by piece:
> >
> > /etc/bindresvport.blacklist
> >
> > Not required to run programs, just a workaround for a conflict between
> > RPC and a handful of services.
> >
> > /etc/ld.so.conf.d/libc.conf
> >
> > Just adds /usr/local/lib; not a required component of a system.
> >
> > /etc/gai.conf
>
> While it is true, not having a dependency between the two makes very
> difficult to handle the
Only if you want to customize it.
> > Consists entirely of commented-out defaults.
> >
> > /sbin/ldconfig
> >
> > Maintaining ld.so.cache makes the system run faster, but the system will
> > run without it. The only caveat: any library packages would need to
> > only run it if it exists.
>
> Given that half of the packages does that in the postinst, that's a lot
> to change. Until they are all changed, that just makes this change
> totally impossible.
Fair enough; that does seem like the biggest issue. Would you consider
this change if those packages did so? Most packages don't do so by
hand, so fixing the various package-building helper packages would get
most of the way there.
(Also briefly entertaining the notion of having some kind of divertable
ldconfig -> /bin/true link. :) There's also the long-standing
discussion about triggerizing ldconfig, though I realize that proves
fairly intricate.)
> > /usr/bin/catchsegv
>
> Ok
>
> > /usr/bin/getconf
>
> Required by POSIX
>
> > /usr/bin/getent
> > /usr/bin/iconv
>
> Required by POSIX
>
> > /usr/bin/ldd
>
> Ok
>
> > /usr/bin/localedef
> > /usr/bin/locale
>
> Required by POSIX
>
> > /usr/bin/tzselect
> > /usr/bin/rpcinfo
> > /usr/bin/zdump
>
> Ok
>
> > None required for a running system, just generally useful.
>
> As said above, most of them are need for POSIX compliance, they have to
> stay on the system.
I had no idea. That does seem to argue for the "Essential: yes" you
suggest below, in which case reversing the dependency seems like the
best solution.
> > So, in general, nothing in libc-bin has to exist for the system to work,
> > and only one thing (ldconfig) needs some extra care to make sure the
> > system can cope without its presence.
>
> Half of the tool are necessary for POSIX compliance. Also libc-bin 2.13
> now provides a C.UTF-8 locale for Debian Policy compliance.
Oh, awesome. I had no idea. Thank you very much, I look forward to
that.
Any straightforward way for a script (.bashrc, for instance) to detect
the existence of C.UTF-8 in order to use it in preference to en_US.UTF-8
if present?
> While I agree it's possible to run a half-broken system without libc-bin,
> that doesn't mean you just want it to be recommended. libc-bin is less
> than 750kB when installed, if you really want to gain space, I would
> suggest you to start by looking at essential packages (or their
> dependencies) taking a few MB.
>
> That's simply a wontfix for now, just to leave you the right to answer.
> Otherwise I would just close this bug. Seriously if you want to make so
> small system that you don't want to install libc-bin, just have a look
> at emdebian or other solutions.
Might you consider moving the manpages to glibc-doc or similar, perhaps?
> > On the flipside, though, libc-bin probably needs "Depends: libc6", since
> > it includes various programs that need libc6.
> >
> > (Related to this: neither libc6 nor libc-bin has "Essential: yes", so
> > programs already can't count on them without a dependency.)
>
> All that said, I agree that we should drop the dependency from libc6 to
> libc-bin (and add the dependency in the other direction), and just make
> libc-bin essential.
Fair enough. That would prove more convenient, and I'd appreciate it
greatly.
Thanks,
Josh Triplett
Reply to: