Hi,

sorry, if this post doubles some other posts already done by others...I
wrote it during a journey and haven't catched yet with the discussion.

Kumba <kumba@g.o>:

> Kumba wrote:
> > 
> > I was talking to Alec last night in -dev (yes, I'm still alive),
> > and I tossed out the idea of using metadata.xml instead of mangling
> > the ebuild filename or even sticking it as the first line in the
> > ebuild (as a hashbang or something gentoo-specific, for example).
> 
> Fleshing out more (And to solicit more thought on this idea --
> insane?).

 Thanks for backing your initial thoughs with some more substance,
although I see some fundamental problems.

> Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just
> an example -- suggest other formats):

 In my eyes metadata.xml should contain only non-essential
informational data.  The description of a local USE flag in metadata.xml
is ok, as that text is not really essential for ebuild operation.  I
remember before EAPI 1 that having a default USE flag was some obscure
operation in package.use.default.  A user/developer could be completely
clueless about that feature and annoyed because some USE flag is pulled
in he did not want.  Having all sourcing/install/processing information
near or inside the ebuild makes it easier (I know we still have
use.mask and the like).  Now your proposal moves essential (to the
package manager, where USE flag descriptions are not) metadata out of
the ebuild.
 What if a submitted ebuild to Bugzilla or by mail comes in?  Without
any special surrounding information ("Hey this ebuild is EAPI 5") you
would have to look up in the PMS which EAPI is appropriate or wonder
about repoman's warnings when trying to commit (and I know people who
use --force quite often).  So apart from having the EAPI information in
the ebuild name or inside it there are no feasible options to store
it.  Though I must confess that a user submitted ebuild could strip
parts of the name in his submission thus destroying that EAPI
information, too.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>