Diego 'Flameeyes' Pettenò kirjoitti:
Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end.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.
At least one reason is that otherwise lots of ebuild submissions would have coreutils/gcc/libc/whatever in DEPEND/RDEPEND.
But why autoconf and automake? Well the easy answer is that those are often used without making sure they are depended upon explicitly… or at least this was the case till me and Martin added autotools.eclass to the tree; nowadays all the ebuilds using autotools should have proper autoconf/automake dependency already, and if they don’t they are broken anyway. So why leaving them in system? And what about m4? m4 is not part of a common Unix system, it’s just an autoconf dependency, why isn’t it just an autoconf dependency?
IMHO these could be removed from the system set. But likely the packages left in there would pull it to the stages any way.
P.S.: 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.
>Well e2fsprogs provides fsck so it's a dep of baselayout. But it wouldn't hurt to cleanup the list even if it doesn't get them removed from stages. I don't know about other system packages but at least baselayout is not really depending on much atm.
Regards, Petteri
signature.asc
Description: OpenPGP digital signature
