Gentoo Archives: gentoo-dev

From: Kumba <kumba@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Sat, 28 Feb 2009 20:53:08
In Reply to: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives by Kumba
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).
8 Fleshing out more (And to solicit more thought on this idea -- insane?).
10 Using mips-sources as an example:
12 # ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild
14 total 116K
15 -rw-r--r-- 1 root root 19K Jan 9 04:10 mips-sources-
16 -rw-r--r-- 1 root root 18K Jan 9 04:10 mips-sources-
17 -rw-r--r-- 1 root root 18K Feb 23 16:43 mips-sources-
20 Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example
21 -- suggest other formats):
23 <eapi pv="" ver="2" />
24 <eapi pv="" ver="2" />
25 <eapi pv="" ver="2" />
27 pv = specifies the package version
28 ver = eapi version.
30 Better names for these values? Suggest! I didn't want to re-use 'api' or
31 anything. Maybe <pms pv="" eapi="2" /> ?
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).
38 /usr/portage/profiles/eapi.list will resemble something like this:
40 sys-kernel/mips-sources-
41 sys-kernel/mips-sources-
42 sys-kernel/mips-sources-
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.
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.
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?)
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.
79 Some other thoughts on the first con, of metadata being updated more frequently
80 -- we allow the use of wildcards:
82 <eapi pv="*" ver="2" />
83 Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this
84 case)
86 <eapi pv="<2.6*" ver="1" />
87 Marks every ebuild version lower than 2.6 as EAPI=1.
89 Basically, the wildcard modifiers Portage currently understands would apply. Or
90 we could limit it to a subset of these wildcards (say, *, <, >, <=, and >=).
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.
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?
104 --
105 Joshua Kinard
106 Gentoo/MIPS
107 kumba@g.o
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."
112 --Emperor Turhan, Centauri Republic