1 |
On Thursday, June 16, 2011 22:13:48 Duncan wrote: |
2 |
> Mike Frysinger posted on Thu, 16 Jun 2011 20:51:36 -0400 as excerpted: |
3 |
> > these are mostly done already via the autotools eclass, so these should |
4 |
> > get dropped from system: |
5 |
> > sys-devel/autoconf sys-devel/automake sys-devel/libtool sys-devel/m4 |
6 |
> |
7 |
> That last comment, on the autotools eclass, suggests a solution, a |
8 |
> basedeps eclass, which most ebuilds could simply inherit. |
9 |
|
10 |
that's not what i was suggesting at all, nor do i think it feasible |
11 |
|
12 |
> The eclass could handle most archiving dependencies automatically, using |
13 |
> source URL extensions to determine type. Similarly with stuff like make |
14 |
> by scanning for calls to it or emake. |
15 |
|
16 |
the automatic code scanning wouldnt work as it would need to consider the |
17 |
default implementation of functions (which really only the PM knows), and even |
18 |
then it cant handle code which is dynamic (like the default PM funcs). |
19 |
if [ -e Makefile ] ; then emake ; fi |
20 |
|
21 |
how do you automatically detect utilities that only the package executes ? |
22 |
|
23 |
> Bash and baselayout would be mandatory, and variables could be used for |
24 |
> quick-list adds and overrides. |
25 |
|
26 |
gee, that sounds exactly like the system set we already have, except this |
27 |
solution generates a lot more overhead (all the execution/caching required to |
28 |
process this new eclass), and more pains. the system set is in the profile |
29 |
which other profiles can easily override (by design). much harder to pull |
30 |
that off with eclasses. |
31 |
|
32 |
> It'd take a LOT of work and testing and may even then not be workable |
33 |
> unless implemented as an arbitrary list that pretty much simply moves the |
34 |
> @system list from its current location into an eclass, but the idea's |
35 |
> interesting. Possible/practical or wishful thinking? |
36 |
|
37 |
impractical wishful thinking |
38 |
|
39 |
further, many of these deps themselves depend on their own existence. |
40 |
coreutils needs expr/touch/tail/head/...... which coreutils provides. bash |
41 |
needs a shell which bash provides. sed needs sed which sed provides. gawk |
42 |
needs gawk which gawk provides. make needs make which make provides. |
43 |
|
44 |
friends also need their friends. make/bash/sed/grep/coreutils pretty much all |
45 |
need each other. which is another reason why they're in the system set. |
46 |
-mike |