On Wed, 16 Feb 2005 17:39:01 +0000 John Mylchreest <[EMAIL PROTECTED]>
wrote:
| > Two issues we'd have with elibs:
| > * even things like eutils set a DEPEND, since patch is a dep.
| > * anything which touches use flags will have to be an eclass, since
| IUSE
| > needs to be set.
| >
| > Is there a good reason for an arbitrary split?
| 
| Most of the perceived problems are speculation or procedural issues,
| although to specify a few examples of this:

Mmm. The IUSE thing is a genuine issue, IMO. Take, for example,
flag-o-matic. It uses the debug USE flag, so it has to set IUSE="debug".
If flag-o were an elib rather than an eclass which doesn't define any
standard (src_unpack etc) functions, every ebuild which inherited it
would have to manually remember to set IUSE="debug" in the ebuild.

The way IUSE works currently is:
* ebuilds set IUSE to whatever flags they themselves use (ignoring
anything they inherit)
* eclasses set IUSE to whatever flags they themselves use (ignoring
anything that inherits them or that they inherit)
* portage treats IUSE as cumulative, strips out dupes and displays the
correct (as of 2.0.fiftysomething) emerge -pv output

With elibs, either:
* they don't set IUSE, in which case the ebuilds have to remember to add
in extra items to avoid breaking emerge -pv
* or they set IUSE, which turns them into an eclass anyway

Of course, if eclass == elib then this is a non-issue :)

Anyone have a different easy solution to mine?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm

Attachment: pgp7Pgk9lX8hT.pgp
Description: PGP signature

Reply via email to