| 1 |
Mike Frysinger posted on Thu, 16 Jun 2011 20:51:36 -0400 as excerpted: |
| 2 |
|
| 3 |
>> An annoying, but valid complaint agains this is that the deps start |
| 4 |
>> getting heavy to maintain for developers, and aren't always viable to |
| 5 |
>> represent. Unpackers for example, are a pain in the ass for current |
| 6 |
>> EAPIs- that could be reduced in pain via addition of basic implicit |
| 7 |
>> deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2). |
| 8 |
> |
| 9 |
> i think you vastly underestimate how bad this is. what you're proposing |
| 10 |
> is the majority list: |
| 11 |
> sys-apps/baselayout (after all, it provides / /usr /usr/share / |
| 12 |
etc) |
| 13 |
> app-shells/bash sys-apps/coreutils sys-apps/gawk sys-apps/grep |
| 14 |
> sys-apps/sed (every autotooled package uses it) |
| 15 |
> sys-apps/which (g'luck tracking down all the consumers) sys-devel/ |
| 16 |
gcc |
| 17 |
> sys-devel/binutils virtual/libc sys-apps/make |
| 18 |
> |
| 19 |
> requiring people to remember to use these deps if their ebuild happens |
| 20 |
> to execute them is silly: |
| 21 |
> sys-apps/diffutils (provides `patch` after all) |
| 22 |
> sys-apps/findutils |
| 23 |
> |
| 24 |
> archiving/compression deps absolutely need to be in the PM. otherwise |
| 25 |
> you're talking about: |
| 26 |
> app-arch/tar (a quick count shows 22k ebuilds need it out of all |
| 27 |
27k) |
| 28 |
> app-arch/gzip (14k ebuilds) |
| 29 |
> app-arch/bzip2 (8k ebuilds) |
| 30 |
> |
| 31 |
> these are mostly done already via the autotools eclass, so these should |
| 32 |
> get dropped from system: |
| 33 |
> sys-devel/autoconf sys-devel/automake sys-devel/libtool sys-devel/ |
| 34 |
m4 |
| 35 |
|
| 36 |
That last comment, on the autotools eclass, suggests a solution, a |
| 37 |
basedeps eclass, which most ebuilds could simply inherit. |
| 38 |
|
| 39 |
The eclass could handle most archiving dependencies automatically, using |
| 40 |
source URL extensions to determine type. Similarly with stuff like make |
| 41 |
by scanning for calls to it or emake. Bash and baselayout would be |
| 42 |
mandatory, and variables could be used for quick-list adds and overrides. |
| 43 |
|
| 44 |
It'd take a LOT of work and testing and may even then not be workable |
| 45 |
unless implemented as an arbitrary list that pretty much simply moves the |
| 46 |
@system list from its current location into an eclass, but the idea's |
| 47 |
interesting. Possible/practical or wishful thinking? |
| 48 |
|
| 49 |
-- |
| 50 |
Duncan - List replies preferred. No HTML msgs. |
| 51 |
"Every nonfree program has a lord, a master -- |
| 52 |
and if you use the program, he is your master." Richard Stallman |
Archives