Re: [gentoo-dev] [RFC] Reducing the size of the system package set

[Mike Frysinger]

On Monday 07 January 2008, Diego 'Flameeyes' Pettenò wrote:
> I already ranted about the fact that the dependency tree of our ebuilds
> is vastly incomplete, as many lack dependency on zlib; trying to get
> this fixed was impossible, as Donnie and other insisted that as zlib was
> in system, we shouldn’t depend on it at all. I disagree, and I would
> like to know why we can’t depend on a system package, but whatever.

the system dep rule isnt hard as in "if it's system, you cannot depend on it".  
that's silly.  it applies to packages which, if they do not exist, the system 
would not be usable.  things like grep/sed/tail/ps/etc... do not belong in 
the depend strings.  you cannot have a usable system without such utilities 
on your system.  that means packages like grep/sed/coreutils/procps/etc... do 
not belong in depend strings.  there is also the issue that these packages 
tend to be swappable based on the system (embedded/bsd/whatever), so listing 
them only causes problems.

> Anyway, as having a complete dependency tree is almost impossible
> because of that, I have an alternative proposal: reducing the size of
> the system package set.  Right now system contains stuff like ncurses,
> readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
> on. Those are packages that certainly would be part of any base Gentoo
> system, but are those actual part of the system set of packages? I
> sincerely doubt it.

for ncurses/readline, they certainly are part of the system set.  that doesnt 
mean they should not show up in depend strings, it just means they are system 
packages that every Gentoo system should have installed.

i have no problem with shunting the rest.  the only thing you need to keep in 
mind is that if we do move all of these things to build-only depend (which 
they are logically), then people who like to depclean their system would 
constantly be removing/adding them.

> The reason of the existence of the system package set is related first
> and foremost to breaking circular dependencies: for instance if any
> package that used the C compiler would depend on gcc, then the packages
> that gcc depends upon would create a circular dependency between gcc and
> itself. Also, specifying libc in almost any ebuild would be quite
> pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv,
> install, …

not really.  the system package set is what went into releases and we wanted 
all of these things in our stage tarballs.  it is nigh impossible to emerge 
anything on a Gentoo system without any of these packages, so forcing them 
all by default didnt cause any problems.

> For what concern the three main libraries, there aren’t that many
> packages using zlib directly nowadays, this is especially easy to spot
> on a system built with --as-needed, as without that you actually do see
> zlib used in every other binary, for indirect dependencies. Nor there
> aren’t tons and tons of packages using readline, or ncurses. Actually in
> my own vserver’s chroot I only found four packages using readline, none
> of them part of system: ruby with the readline extension (uhm I wonder
> if I should ask for this to become an USE flag, I certainly don’t need
> it and I’d rather get rid of it), psql from postgresql (which maybe it’s
> still good to have with readline compiled in, but I could easily get rid
> of), bc (which is just an e2fsprogs build-dep, and I could build without
> readline just fine), and mysql.

bash uses readline as well ... but currently statically links it in ... i 
could (should?) change that ...

> A little bit different the status of ncurses, which is used by screen,
> gettext (only a build-dep, not needed for runtime on Linux anyway),
> procps, psmisc and util-linux (and I wonder why we don’t have a switch
> to turn it off), texinfo (wonder why we can’t remove it entirely
> actually) and yet again ruby. Still, I wonder why ncurses is in system
> rather than being properly on the dependencies list of those packages.

not sure how you missed the fact that *bash* needs it.  that seems pretty 
critical.

> As for perl, that’s probably a bit more justified, there are tons of
> packages using perl directly or indirectly, especially in build
> systems. But I would like those to depend on perl properly rather than
> having perl in system, as there are cases where perl is not really
> needed at runtime at least.

i'd say quite the opposite ... requiring perl in system blows.  it's there for 
two reasons: autotools and openssl.  but both are build time requirements 
only.

> And the only users of gnuconfig are the packages making use of the old
> and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a
> dependency of portage then?

you've missed all of the autotool reliance on gnuconfig.  they symlink their 
config files to gnuconfig.  the fact that it is tied into econf is irrelevant 
i think ... any autotool based package has a dep on gnuconfig as bundled 
config files should always update to this.  how it gets updated doesnt 
matter.  if your package manager isnt auto-updating things, it sucks.  as for 
how to express that depend, it's a crap shoot.

> So there are more things that were brought to my attention, like ssh,
> flex, bison, e2fsprogs, and so on. We should probably look into what to
> keep, rather than what to remove.

flex/bison are in the exact same boat as autotools.  dont know why you 
separated them out.  openssh and e2fsprogs are part of the system set because 
every Gentoo system out there should have them installed.  if you dont like 
it, feel free to tweak your files locally, but to attempt to account for a 
few people at the detriment of 99.9% of the people out there makes no sense 
at all.
-mike