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
signature.asc
Description: This is a digitally signed message part.
