| 1 |
Kumba wrote: |
| 2 |
> |
| 3 |
> I was talking to Alec last night in -dev (yes, I'm still alive), and I |
| 4 |
> tossed out the idea of using metadata.xml instead of mangling the ebuild |
| 5 |
> filename or even sticking it as the first line in the ebuild (as a |
| 6 |
> hashbang or something gentoo-specific, for example). |
| 7 |
|
| 8 |
Fleshing out more (And to solicit more thought on this idea -- insane?). |
| 9 |
|
| 10 |
Using mips-sources as an example: |
| 11 |
|
| 12 |
# ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild |
| 13 |
|
| 14 |
total 116K |
| 15 |
-rw-r--r-- 1 root root 19K Jan 9 04:10 mips-sources-2.6.20.18.ebuild |
| 16 |
-rw-r--r-- 1 root root 18K Jan 9 04:10 mips-sources-2.6.27.10.ebuild |
| 17 |
-rw-r--r-- 1 root root 18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild |
| 18 |
|
| 19 |
|
| 20 |
Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example |
| 21 |
-- suggest other formats): |
| 22 |
|
| 23 |
<eapi pv="2.6.20.18" ver="2" /> |
| 24 |
<eapi pv="2.6.27.10" ver="2" /> |
| 25 |
<eapi pv="2.6.28.7" ver="2" /> |
| 26 |
|
| 27 |
pv = specifies the package version |
| 28 |
ver = eapi version. |
| 29 |
|
| 30 |
Better names for these values? Suggest! I didn't want to re-use 'api' or |
| 31 |
anything. Maybe <pms pv="2.6.28.7" eapi="2" /> ? |
| 32 |
|
| 33 |
|
| 34 |
Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the |
| 35 |
same as whatever parses out the <use> tags will run and extract this data, and |
| 36 |
update /usr/portage/profiles/eapi.list (example name). |
| 37 |
|
| 38 |
/usr/portage/profiles/eapi.list will resemble something like this: |
| 39 |
|
| 40 |
sys-kernel/mips-sources-2.6.20.18:2 |
| 41 |
sys-kernel/mips-sources-2.6.27.10:2 |
| 42 |
sys-kernel/mips-sources-2.6.28.7:2 |
| 43 |
|
| 44 |
|
| 45 |
Upon installing the package by whatever package manager (portage is my example), |
| 46 |
it will process this eapi.list, much like it does use.desc and use.local.desc, |
| 47 |
and therefore know all it needs to know, then it can source the ebuild and use |
| 48 |
whatever logic it needs to follow that specific EAPI. That is if my assumption |
| 49 |
is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild |
| 50 |
itself being sourced. If not, well, I dunno then. I'm guessing here. |
| 51 |
|
| 52 |
|
| 53 |
The pros of this that I can see: |
| 54 |
- No changes to the current filename structure. Things stay the name, CVS |
| 55 |
history is retained because existing files aren't renamed (we're not on git just |
| 56 |
yet). |
| 57 |
- No special markers, comments, or bash vars inside the ebuild. Covers some of |
| 58 |
the other cons that were presented. |
| 59 |
- Older package managers won't read eapi.list, and can resume their default |
| 60 |
behavior of EAPI=0. Allows backwards compatibility. |
| 61 |
- Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, |
| 62 |
so there won't be a big rush to update every package/metadata in the tree. |
| 63 |
Allows for slow, controlled adoption. |
| 64 |
|
| 65 |
Cons that I can see: |
| 66 |
- metadata.xml gets updated more frequently because specific versions can get |
| 67 |
cited (workaround idea, see below) |
| 68 |
- Backend has to do extra work (minimal? Can infra comment on the feasibility |
| 69 |
of this?) |
| 70 |
|
| 71 |
I'm suggesting this mostly because both ideas of embedding the EAPI value in the |
| 72 |
filename and inside the ebuild seem like ugly workarounds. Others are also |
| 73 |
noting other problems with both of these approaches. EAPI also feels more like |
| 74 |
a metadata-type thing anyways. I mean, if we're already storing local USE flags |
| 75 |
in it, why not EAPI stuff? I'm a tad behind on the whole discussion, I know, |
| 76 |
but why not toss the idea out there. |
| 77 |
|
| 78 |
|
| 79 |
Some other thoughts on the first con, of metadata being updated more frequently |
| 80 |
-- we allow the use of wildcards: |
| 81 |
|
| 82 |
<eapi pv="*" ver="2" /> |
| 83 |
Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this |
| 84 |
case) |
| 85 |
|
| 86 |
<eapi pv="<2.6*" ver="1" /> |
| 87 |
Marks every ebuild version lower than 2.6 as EAPI=1. |
| 88 |
|
| 89 |
Basically, the wildcard modifiers Portage currently understands would apply. Or |
| 90 |
we could limit it to a subset of these wildcards (say, *, <, >, <=, and >=). |
| 91 |
|
| 92 |
|
| 93 |
Obviously, tools like repoman would need to be able to read metadata as well |
| 94 |
(can it? I don't know) and make sure that the versions specified in the 'pv' |
| 95 |
value exist in the directory before commit. Either by specific value or by |
| 96 |
expanding the wildcard notation and then cross-referencing the files listed in |
| 97 |
the directory and with CVS/git/whatever. |
| 98 |
|
| 99 |
|
| 100 |
But to be honest, none of the ideas, even my own, seems like "the best" idea. I |
| 101 |
think of mine as less intrusive to the tree and less visible to the end users |
| 102 |
and the package managers, but maybe there's other options not thought of yet? |
| 103 |
|
| 104 |
-- |
| 105 |
Joshua Kinard |
| 106 |
Gentoo/MIPS |
| 107 |
kumba@g.o |
| 108 |
|
| 109 |
"The past tempts us, the present confuses us, the future frightens us. And our |
| 110 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 111 |
|
| 112 |
--Emperor Turhan, Centauri Republic |
Archives