Gentoo Archives: gentoo-dev

From: (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=)
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RFC] Reducing the size of the system package set
Date: Mon, 07 Jan 2008 23:43:25
1 Here comes the official proposal, copy and paste from my blog with an
2 extra post scriptum at the end.
4 I already ranted about the fact that the dependency tree of our ebuilds
5 is vastly incomplete, as many lack dependency on zlib; trying to get
6 this fixed was impossible, as Donnie and other insisted that as zlib was
7 in system, we shouldn’t depend on it at all. I disagree, and I would
8 like to know why we can’t depend on a system package, but whatever.
10 Anyway, as having a complete dependency tree is almost impossible
11 because of that, I have an alternative proposal: reducing the size of
12 the system package set. Right now system contains stuff like ncurses,
13 readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
14 on. Those are packages that certainly would be part of any base Gentoo
15 system, but are those actual part of the system set of packages? I
16 sincerely doubt it.
18 The reason of the existence of the system package set is related first
19 and foremost to breaking circular dependencies: for instance if any
20 package that used the C compiler would depend on gcc, then the packages
21 that gcc depends upon would create a circular dependency between gcc and
22 itself. Also, specifying libc in almost any ebuild would be quite
23 pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv,
24 install, …
26 But why autoconf and automake? Well the easy answer is that those are
27 often used without making sure they are depended upon explicitly… or at
28 least this was the case till me and Martin added autotools.eclass to the
29 tree; nowadays all the ebuilds using autotools should have proper
30 autoconf/automake dependency already, and if they don’t they are broken
31 anyway. So why leaving them in system? And what about m4? m4 is not part
32 of a common Unix system, it’s just an autoconf dependency, why isn’t it
33 just an autoconf dependency?
35 For what concern the three main libraries, there aren’t that many
36 packages using zlib directly nowadays, this is especially easy to spot
37 on a system built with --as-needed, as without that you actually do see
38 zlib used in every other binary, for indirect dependencies. Nor there
39 aren’t tons and tons of packages using readline, or ncurses. Actually in
40 my own vserver’s chroot I only found four packages using readline, none
41 of them part of system: ruby with the readline extension (uhm I wonder
42 if I should ask for this to become an USE flag, I certainly don’t need
43 it and I’d rather get rid of it), psql from postgresql (which maybe it’s
44 still good to have with readline compiled in, but I could easily get rid
45 of), bc (which is just an e2fsprogs build-dep, and I could build without
46 readline just fine), and mysql.
48 A little bit different the status of ncurses, which is used by screen,
49 gettext (only a build-dep, not needed for runtime on Linux anyway),
50 procps, psmisc and util-linux (and I wonder why we don’t have a switch
51 to turn it off), texinfo (wonder why we can’t remove it entirely
52 actually) and yet again ruby. Still, I wonder why ncurses is in system
53 rather than being properly on the dependencies list of those packages.
55 As for perl, that’s probably a bit more justified, there are tons of
56 packages using perl directly or indirectly, especially in build
57 systems. But I would like those to depend on perl properly rather than
58 having perl in system, as there are cases where perl is not really
59 needed at runtime at least.
61 And the only users of gnuconfig are the packages making use of the old
62 and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a
63 dependency of portage then?
65 There are probably other packages that should, in my opinion, be removed
66 From system, but these are certainly some of the most
67 common. Unfortunately there’s a recursive problem here: to remove the
68 packages from system without breaking stuff you’d need a proper deptree,
69 and to get a proper deptree you need to remove the packages from
70 system. This is what actually stops me from proposing this right away…
72 P.S.:
74 So there are more things that were brought to my attention, like ssh,
75 flex, bison, e2fsprogs, and so on. We should probably look into what to
76 keep, rather than what to remove.
78 Also, rocket proposed me to try building a stage with a slimmed down
79 system. I could try, but it would be a waste of time if we then decide
80 not to go this route, and that's _a lot_ of time that would go to waste,
81 so I'd rather first see what the other devs think, before going to do
82 the actual tests.
84 --
85 Diego "Flameeyes" Pettenò