On Tue, Feb 24, 2009 at 5:21 PM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> My notes so far:
>
> 1) Status quo
> *- does not allow changing inherit
> *- bash version in global scope
> *- global scope in general is quite locked down
>
> 2) EAPI in file extension
> *- Allows changing global scope and the internal format of the ebuild
> *a) .ebuild-<eapi>
> * *- ignored by current Portage
> *b) .<eapi>.ebuild
> * *- current Portage does not work with this
> *c) .<eapi>.<new extension>
> * *- ignored by current Portage
>
> 3) EAPI in locked down place in the ebuild
> *- Allows changing global scope
> *- EAPI can't be changed in an existing ebuild so the PM can trust
> * *the value in the cache
> *- Does not allow changing versioning rules unless version becomes a
> * *normal metadata variable
> * ** Needs more accesses to cache as now you don't have to load older
> * * *versions if the latest is not masked
> *a) <new extension>
> *b) new subdirectory like ebuilds/
> *- we could drop extension all together so don't have to argue about
> * *it any more
> *- more directory reads to get the list of ebuilds in a repository
> *c) .ebuild in current directory
> *- needs one year wait
>

I don't see the point of some of these... a shorter extension would be
nice but not really necessary.

.<eapi>.ebuild

so like .2.ebuild 'cause that'd work great?
smith-1.3.6.2.ebuild better yet vanilla-sources-2.6.28.2.2.ebuild

yeah I can see that working out... no it wouldn't

or maybe smith-1.3.6.eapi-2.ebuild

just too long

here's an idea, perhaps not a great one... but perhaps it'll make
someone else think...

how about this on the first line

# eapi-2

and instead of sourcing it, have portage match it with a regex first,
figure out the eapi, then source it.

I don't know if I really like like what I'm proposing, but I don't see
anything else that looks good.
--
Caleb Cushing

http://xenoterracide.blogspot.com

My 2¢ :

Keep the EAPI inside the ebuild itself. On the first line, on the fifth
line, as an argument with the shebang, as a comment, as a variable, as a
function call, ...


I really don't care what it looks like, as long as it's inside the ebuild.

Cheers,

Rémi

EAPI inside ebuild is the best solution. If we really have to put it
inside filename, keep it out of extension, like 2) b) suggests.

--
Peter.

> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage

This is the solution that solves most problems. Going with something
else is just a way of doing it wrong for the sake of it.

- ferdy

Petteri Räty wrote:
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

I have been thinking about this specific option. I will admit I don't
know if this has already been noted, but would this create the
possibility of multiple ebuilds with the same $C/$P-$PV?

Currently the filesystem enforces the uniqueness of that tuple, will
that uniqueness be allowed to lapse? (i.e. allow multiple ebuilds for
the same $C/$P-$PV with different EAPIs?)

If not, how is anyone proposing to enforce the uniqueness here?

Just a silly thought...
RobbieAB

On Sat, 28 Feb 2009 19:39:36 +0000
Robert Bridge <robert@robbieab.com> wrote:
> I have been thinking about this specific option. I will admit I don't
> know if this has already been noted, but would this create the
> possibility of multiple ebuilds with the same $C/$P-$PV?

GLEP 55 forbids it.

Note that it's already possible to have multiple equal versions of the
same thing (1.0_alpha0 equals 000001.0_alpha-r0), and it's already
illegal. None of this is altered by any of the proposals.

--
Ciaran McCreesh

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

Hi,

Petteri Räty <betelgeuse@gentoo.org>:

> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a
> useful experiment to see if we can control ourselves

Thanks.

> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

All of them are ugly as hell. Though a) has my preference because of
the added flexibility. Can we use cool names instead of numbers as
eapi or omit the dash? => .ebuild3 or .ebuild-upyours

> 3) EAPI in locked down place in the ebuild

No, you never know when you need the flexibility.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

Am Montag, den 02.03.2009, 08:31 +0100 schrieb Christian Faulhammer:
> Hi,
>
> Petteri Räty <betelgeuse@gentoo.org>:
>
> > Let's try something new. I would like to get opinions from as many
> > people as possible about GLEP 55 and alternatives listed here in order
> > to get some idea what the general developer pool thinks. Everyone is
> > only allowed to post a single reply to this thread in order to make it
> > easy to read through. The existing thread should be used for actual
> > discussion about the GLEP and the alternatives. This should be a
> > useful experiment to see if we can control ourselves
>
> Thanks.
>
> > 2) EAPI in file extension
> > - Allows changing global scope and the internal format of the ebuild
> > a) .ebuild-<eapi>
> > - ignored by current Portage
> > b) .<eapi>.ebuild
> > - current Portage does not work with this
> > c) .<eapi>.<new extension>
> > - ignored by current Portage
>
> All of them are ugly as hell. Though a) has my preference because of
> the added flexibility. Can we use cool names instead of numbers as
> eapi or omit the dash? => .ebuild3 or .ebuild-upyours

Should be possible I guess.
The EAPI used in the tree must be a number (according to PMS). External
projects or overlays may/must use a name instead.

Thanks Petteri,

>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down

lets move on!

>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

2 a) and 2 c) are fine by me.

>
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait

no thanks.

>
> Regards,
> Petteri

regards
Thilo