On Tuesday, June 14, 2011 19:27:47 Brian Harring wrote: > On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote: > > On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring <[email protected]> wrote: > > > The implicit system set dependency thing really, really needs to die; > > > at the time of the rule, portage couldn't handle resolving graphs of > > > that sort. ?PM resolvers for gentoo are generally a fair bit saner > > > now thus doing what you're suggesting isn't really beneficial (frankly > > > it causes some issues for stages, as zac noted). > > > > ++ > > > > It seems to me that the best policy would be for every package to just > > list all its dependencies, and then users are free to run the default > > experience that includes everything in @system, or a more trimmed-down > > experience. > > An annoying, but valid complaint agains this is that the deps start > getting heavy to maintain for developers, and aren't always viable to > represent. Unpackers for example, are a pain in the ass for current > EAPIs- that could be reduced in pain via addition of basic implicit > deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2).
i think you vastly underestimate how bad this is. what you're proposing is
the majority list:
sys-apps/baselayout (after all, it provides / /usr /usr/share /etc)
app-shells/bash
sys-apps/coreutils
sys-apps/gawk
sys-apps/grep
sys-apps/sed (every autotooled package uses it)
sys-apps/which (g'luck tracking down all the consumers)
sys-devel/gcc
sys-devel/binutils
virtual/libc
sys-apps/make
requiring people to remember to use these deps if their ebuild happens to
execute them is silly:
sys-apps/diffutils (provides `patch` after all)
sys-apps/findutils
archiving/compression deps absolutely need to be in the PM. otherwise you're
talking about:
app-arch/tar (a quick count shows 22k ebuilds need it out of all 27k)
app-arch/gzip (14k ebuilds)
app-arch/bzip2 (8k ebuilds)
these are mostly done already via the autotools eclass, so these should get
dropped from system:
sys-devel/autoconf
sys-devel/automake
sys-devel/libtool
sys-devel/m4
> The trickier point is gcc, but in my view, that's where we get the
> most gain- if the toolchain is represented in the deps it makes
> integrated cross compilation easier (keyword is integrated; crossdev
> already makes it reasonably straightforward I realize).
i dont understand this at all. sounds to me like this complicates cross-
compilation unnecessarily.
-mike
signature.asc
Description: This is a digitally signed message part.
