[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
From:       Kumba <kumba () gentoo ! org>
Date:       2009-02-28 20:52:50
Message-ID: 49A9A422.5040009 () gentoo ! org
[Download RAW message or body]

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?).

Using mips-sources as an example:

# ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild

total 116K
-rw-r--r-- 1 root root  19K Jan  9 04:10 mips-sources-2.6.20.18.ebuild
-rw-r--r-- 1 root root  18K Jan  9 04:10 mips-sources-2.6.27.10.ebuild
-rw-r--r-- 1 root root  18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild


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

<eapi pv="2.6.20.18" ver="2" />
<eapi pv="2.6.27.10" ver="2" />
<eapi pv="2.6.28.7" ver="2" />

pv = specifies the package version
ver = eapi version.

Better names for these values? Suggest!  I didn't want to re-use 'api' or 
anything.  Maybe <pms pv="2.6.28.7" eapi="2" /> ?


Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the 
same as whatever parses out the <use> tags will run and extract this data, and 
update /usr/portage/profiles/eapi.list  (example name).

/usr/portage/profiles/eapi.list will resemble something like this:

sys-kernel/mips-sources-2.6.20.18:2
sys-kernel/mips-sources-2.6.27.10:2
sys-kernel/mips-sources-2.6.28.7:2


Upon installing the package by whatever package manager (portage is my example), 
it will process this eapi.list, much like it does use.desc and use.local.desc, 
and therefore know all it needs to know, then it can source the ebuild and use 
whatever logic it needs to follow that specific EAPI.  That is if my assumption 
is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild 
itself being sourced.  If not, well, I dunno then.  I'm guessing here.


The pros of this that I can see:
- No changes to the current filename structure.  Things stay the name, CVS 
history is retained because existing files aren't renamed (we're not on git just 
yet).
- No special markers, comments, or bash vars inside the ebuild.  Covers some of 
the other cons that were presented.
- Older package managers won't read eapi.list, and can resume their default 
behavior of EAPI=0.  Allows backwards compatibility.
- Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, 
so there won't be a big rush to update every package/metadata in the tree. 
Allows for slow, controlled adoption.

Cons that I can see:
- metadata.xml gets updated more frequently because specific versions can get 
cited (workaround idea, see below)
- Backend has to do extra work (minimal?  Can infra comment on the feasibility 
of this?)

I'm suggesting this mostly because both ideas of embedding the EAPI value in the 
filename and inside the ebuild seem like ugly workarounds.  Others are also 
noting other problems with both of these approaches.  EAPI also feels more like 
a metadata-type thing anyways.  I mean, if we're already storing local USE flags 
in it, why not EAPI stuff?  I'm a tad behind on the whole discussion, I know, 
but why not toss the idea out there.


Some other thoughts on the first con, of metadata being updated more frequently 
-- we allow the use of wildcards:

<eapi pv="*" ver="2" />
Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this 
case)

<eapi pv="<2.6*" ver="1" />
Marks every ebuild version lower than 2.6 as EAPI=1.

Basically, the wildcard modifiers Portage currently understands would apply.  Or 
we could limit it to a subset of these wildcards (say, *, <, >, <=, and >=).


Obviously, tools like repoman would need to be able to read metadata as well 
(can it?  I don't know) and make sure that the versions specified in the 'pv' 
value exist in the directory before commit.  Either by specific value or by 
expanding the wildcard notation and then cross-referencing the files listed in 
the directory and with CVS/git/whatever.


But to be honest, none of the ideas, even my own, seems like "the best" idea.  I 
think of mine as less intrusive to the tree and less visible to the end users 
and the package managers, but maybe there's other options not thought of yet?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[prev in list] [next in list] [prev in thread] [next in thread]