1 |
Here comes the official proposal, copy and paste from my blog with an |
2 |
extra post scriptum at the end. |
3 |
|
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. |
9 |
|
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. |
17 |
|
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, … |
25 |
|
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? |
34 |
|
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. |
47 |
|
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. |
54 |
|
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. |
60 |
|
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? |
64 |
|
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… |
71 |
|
72 |
P.S.: |
73 |
|
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. |
77 |
|
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. |
83 |
|
84 |
-- |
85 |
Diego "Flameeyes" Pettenò |
86 |
http://farragut.flameeyes.is-a-geek.org/ |