Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Packages that explicitly DEPEND on sys-apps/sed
Date: Fri, 17 Jun 2011 02:46:57
Message-Id: 201106162246.16663.vapier@gentoo.org
In Reply to: [gentoo-dev] Re: Packages that explicitly DEPEND on sys-apps/sed by Duncan <1i5t5.duncan@cox.net>
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

Attachments

File name MIME type
signature.asc application/pgp-signature