* Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
@ 2009-02-28 20:52 99% ` Kumba
0 siblings, 0 replies; 1+ results
From: Kumba @ 2009-02-28 20:52 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2009-02-24 22:21 [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Petteri Räty
2009-02-26 3:13 ` Kumba
2009-02-28 20:52 99% ` Kumba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox