Mike Frysinger posted on Thu, 16 Jun 2011 20:51:36 -0400 as excerpted:

>> 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

That last comment, on the autotools eclass, suggests a solution, a 
basedeps eclass, which most ebuilds could simply inherit.

The eclass could handle most archiving dependencies automatically, using 
source URL extensions to determine type.  Similarly with stuff like make 
by scanning for calls to it or emake.  Bash and baselayout would be 
mandatory, and variables could be used for quick-list adds and overrides.

It'd take a LOT of work and testing and may even then not be workable 
unless implemented as an arbitrary list that pretty much simply moves the 
@system list from its current location into an eclass, but the idea's 
interesting.  Possible/practical or wishful thinking?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to