Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed

[Mike Frysinger]

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 <ferringb@×××××.com> 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