Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Cc: "Diego 'Flameeyes' Pettenò" <flameeyes@×××××.com>
Subject: Re: [gentoo-dev] [RFC] Reducing the size of the system package set
Date: Wed, 09 Jan 2008 20:57:39
In Reply to: [gentoo-dev] [RFC] Reducing the size of the system package set by (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=)
1 On Monday 07 January 2008, Diego 'Flameeyes' Pettenò wrote:
2 > I already ranted about the fact that the dependency tree of our ebuilds
3 > is vastly incomplete, as many lack dependency on zlib; trying to get
4 > this fixed was impossible, as Donnie and other insisted that as zlib was
5 > in system, we shouldn’t depend on it at all. I disagree, and I would
6 > like to know why we can’t depend on a system package, but whatever.
8 the system dep rule isnt hard as in "if it's system, you cannot depend on it".
9 that's silly. it applies to packages which, if they do not exist, the system
10 would not be usable. things like grep/sed/tail/ps/etc... do not belong in
11 the depend strings. you cannot have a usable system without such utilities
12 on your system. that means packages like grep/sed/coreutils/procps/etc... do
13 not belong in depend strings. there is also the issue that these packages
14 tend to be swappable based on the system (embedded/bsd/whatever), so listing
15 them only causes problems.
17 > Anyway, as having a complete dependency tree is almost impossible
18 > because of that, I have an alternative proposal: reducing the size of
19 > the system package set. Right now system contains stuff like ncurses,
20 > readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
21 > on. Those are packages that certainly would be part of any base Gentoo
22 > system, but are those actual part of the system set of packages? I
23 > sincerely doubt it.
25 for ncurses/readline, they certainly are part of the system set. that doesnt
26 mean they should not show up in depend strings, it just means they are system
27 packages that every Gentoo system should have installed.
29 i have no problem with shunting the rest. the only thing you need to keep in
30 mind is that if we do move all of these things to build-only depend (which
31 they are logically), then people who like to depclean their system would
32 constantly be removing/adding them.
34 > The reason of the existence of the system package set is related first
35 > and foremost to breaking circular dependencies: for instance if any
36 > package that used the C compiler would depend on gcc, then the packages
37 > that gcc depends upon would create a circular dependency between gcc and
38 > itself. Also, specifying libc in almost any ebuild would be quite
39 > pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv,
40 > install, …
42 not really. the system package set is what went into releases and we wanted
43 all of these things in our stage tarballs. it is nigh impossible to emerge
44 anything on a Gentoo system without any of these packages, so forcing them
45 all by default didnt cause any problems.
47 > For what concern the three main libraries, there aren’t that many
48 > packages using zlib directly nowadays, this is especially easy to spot
49 > on a system built with --as-needed, as without that you actually do see
50 > zlib used in every other binary, for indirect dependencies. Nor there
51 > aren’t tons and tons of packages using readline, or ncurses. Actually in
52 > my own vserver’s chroot I only found four packages using readline, none
53 > of them part of system: ruby with the readline extension (uhm I wonder
54 > if I should ask for this to become an USE flag, I certainly don’t need
55 > it and I’d rather get rid of it), psql from postgresql (which maybe it’s
56 > still good to have with readline compiled in, but I could easily get rid
57 > of), bc (which is just an e2fsprogs build-dep, and I could build without
58 > readline just fine), and mysql.
60 bash uses readline as well ... but currently statically links it in ... i
61 could (should?) change that ...
63 > A little bit different the status of ncurses, which is used by screen,
64 > gettext (only a build-dep, not needed for runtime on Linux anyway),
65 > procps, psmisc and util-linux (and I wonder why we don’t have a switch
66 > to turn it off), texinfo (wonder why we can’t remove it entirely
67 > actually) and yet again ruby. Still, I wonder why ncurses is in system
68 > rather than being properly on the dependencies list of those packages.
70 not sure how you missed the fact that *bash* needs it. that seems pretty
71 critical.
73 > As for perl, that’s probably a bit more justified, there are tons of
74 > packages using perl directly or indirectly, especially in build
75 > systems. But I would like those to depend on perl properly rather than
76 > having perl in system, as there are cases where perl is not really
77 > needed at runtime at least.
79 i'd say quite the opposite ... requiring perl in system blows. it's there for
80 two reasons: autotools and openssl. but both are build time requirements
81 only.
83 > And the only users of gnuconfig are the packages making use of the old
84 > and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a
85 > dependency of portage then?
87 you've missed all of the autotool reliance on gnuconfig. they symlink their
88 config files to gnuconfig. the fact that it is tied into econf is irrelevant
89 i think ... any autotool based package has a dep on gnuconfig as bundled
90 config files should always update to this. how it gets updated doesnt
91 matter. if your package manager isnt auto-updating things, it sucks. as for
92 how to express that depend, it's a crap shoot.
94 > So there are more things that were brought to my attention, like ssh,
95 > flex, bison, e2fsprogs, and so on. We should probably look into what to
96 > keep, rather than what to remove.
98 flex/bison are in the exact same boat as autotools. dont know why you
99 separated them out. openssh and e2fsprogs are part of the system set because
100 every Gentoo system out there should have them installed. if you dont like
101 it, feel free to tweak your files locally, but to attempt to account for a
102 few people at the detriment of 99.9% of the people out there makes no sense
103 at all.
104 -mike


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] [RFC] Reducing the size of the system package set Chris Gianelloni <wolf31o2@g.o>