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-
-rw-r--r-- 1 root root  18K Jan  9 04:10 mips-sources-
-rw-r--r-- 1 root root  18K Feb 23 16:43 mips-sources-

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

<eapi pv="" ver="2" />
<eapi pv="" ver="2" />
<eapi pv="" 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="" 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:


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

"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

Reply via email to