Brian Harring wrote:
>
> 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as
> the first statement (simplest way).
> pros:
> - global scope changes can occur (inherit mechanism changes
> included).
> - expanding on the first, auto inherits (pkg level) are possible-
> effectively when eapi gets invoked the manager is in control and
> can do whatever is desired setting up the env wise.
> - bash version requirements can be leveled (bash parses as it goes,
> meaning that essentially it won't parse what follows 'eapi 2' till
> that command statement finishes)
> - fits w/ the existing semantics nicely enough.
> cons:
> - mangling the version rules for pkgs still isn't possible; no -scm.
> Arguable if -scm is even desired, but being explicit about it not
> covering this.
> - transition is slightly icky; basically one of the following is
> required-
> a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason
> for this is that current managers obviously lack an eapi function,
> to make managers available *now* blow up the || die is required.
> This solution can be deployed now, no transition required although
> at some point stating "eapi is required retroactively for all
> eapis" would be wise to eliminate the need for the || die (cut
> support basically for old managers)
> b) bashrc trickery, defines an eapi if it's unset. Said eapi
> function exports EAPI=$1, optionally triggering a die if the eapi
> isn't 0,1,2 (since any later eapi would require a manager upgrade
> which would also have the eapi function).
>
> Personally, if g54 is ixnayed #4 I tend to think is the best option
> out there- if g54 is forced in, g55 (or at least something that
> adjusts the extension to make it invisible to current managers) is
> required.
>
> Commentary? Tend to think #4 is the most aesthetically pleasing to
> folk, but who knows...
> ~harring

I really like this idea, but nobody else seems to have commented on it.

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Genkernel + Release Engineering Lead

Petteri Räty wrote:
> 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
>
> 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
>
> Regards,
> Petteri
>

Another option which I haven't seen mentioned here yet would be to just
specify that the method of finding the EAPI depends on the file
extension. Then, anything with a .ebuild extension can be sourced with
bash to find the EAPI, and ebuild formats incompatible with that could
use another file extension. This would work with current package
managers, while still providing a mechanism for incompatible format
changes in the future. It's also aesthetically nicer than current
proposals, since the file extension would indicate something about the
contents of the file.

Or, to put it another way, this would formalize the difference between
the ebuild format (which is currently bash throughout the tree), and the
EAPI. I don't think anybody would oppose a file extension change for a
format change, as opposed to an EAPI change.

--Ravi

Petteri Räty wrote:

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


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).


It's nothing fully fleshed out, and I know parsing XML is about as much fun as
sticking your tongue into a cross-cut paper shredder, but I figured why not toss
it out there?


Add a tag like this to metadata.xml

<eapi pv="2.6.28.7" version="1" />

pv = Package Version (incl. revision if needed).
v = EAPI version.

Other variants:
<eapi version="1">mips-sources-2.6.28.7</eapi>
<eapi pv="2.6.28.7">1</eapi>

and such.

This allows portage or whatever to associate the chosen/desired EAPI level with
a given ebuild version in portage (so the above examples would match
mips-sources-2.6.28.7.ebuild)


I think there's some other magic going on after metadata is updated in portage,
like the whole use.local.desc auto-updating. I figure something like this could
also be implemented, maybe even in the same way whereby a backend script parses
this out and create a /usr/portage/profiles/eapi.list file that links package
revisions with the set eapi level. Then let the various package managers do
whatever it is that they do to make use of this information.


Call it random brainstorming. No idea on the pros & cons -- I haven't even
looked at g55 just 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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petteri Räty wrote:
> 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
>
> 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

I don't want to stick with the status quo since being able to probe
the EAPI without sourcing the ebuild is quite useful. Among other
things, it allows the package manager to avoid the overhead of
sourcing the ebuild in case neither the EAPI nor the cache format is
understood, which solves a problem [1] discussed in the thread about
adding DIGESTS data to the cache.

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

I'd prefer not to introduce an infinite series of file extensions.
To me that just seems too unconventional.

> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

Either of these is fine with 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

I think it's alright to change the EAPI in an existing ebuild. Since
you can simply parse the EAPI instead of sourcing the ebuild, having
a valid cache isn't so important.

> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable

As said by Richard [2], it's alright to change the version rules.
Since you can simply parse the EAPI, it's not appreciably less
accessible than if the EAPI is embedded in the file name.

> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked

Accessing the cache or parsing the EAPI is relatively inexpensive
compared to sourcing the ebuild, so it's not really a problem.
Again, once you can parse the EAPI, it's not appreciably less
accessible then if the EAPI is embedded in the file name.

> a) <new extension>

I think a new extension is preferable to a directory.

> 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

You really only need to wait in order to avoid things like warning
messages about invalid name/version (if you want to do naming
convention changes). If the name/version appear valid, the existing
cache entries will prevent the ebuild from being sourced by existing
versions of portage (as long as the timestamp of the cache entry
matches the timestamp of the ebuild).

[1]
http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_bf3aa0199bb521b263b19b4997a0429c.xml
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmmKkoACgkQ/ejvha5XGaP+2gCfZvkKYypzKydZ+1+sShQkJKr3
ObAAoNr1r9E9eNRCAisahJyqcu6FDV3S
=kj8B
-----END PGP SIGNATURE-----

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> 3) EAPI in locked down place in the ebuild

There's a less extreme variant on this that's slightly cleaner, and
with appropriate weaseling is also less messy. Simply add the following
very carefully worded additional requirement for future EAPIs, and
retroactively impose it upon current ones:

If EAPI is to be set, it must be set strictly before any global scope
command or package manager defined function is called. Once set, EAPI
must not be set to a different value.

Then, the migration path is as follows:

* Fix existing violations (including ones in overlays). Wait a while
until everyone's synced.

* Get package managers to make use of these stricter requirements to
avoid barfing ickily when using things with future EAPIs with
different global scope rules.

* Wait a year. New EAPIs can come out in the mean time, but they can't
change global scope behaviour.

* Use that year to migrate to the key=value cache format with a second,
package-manager-only versioned variable that lets package managers
check cache validity even for unsupported EAPIs so long as there
aren't any cache validation rule changes.

* Change global scope behaviour in new EAPIs at will, but not versioning
rules.

Note that this is functionally equivalent to Brian's eapi as a function
proposal, but much less messy. It's also as powerful for the package
manager as fixed-position, but less inflexible. So if you must go with
something other than GLEP 55, along with all the restrictions and mess
that doing so imposes, this is the one to pick...

--
Ciaran McCreesh

On Thu, 26 Feb 2009 18:07:32 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> There's a less extreme variant on this that's slightly cleaner, and
> with appropriate weaseling is also less messy. Simply add the
> following very carefully worded additional requirement for future
> EAPIs, and retroactively impose it upon current ones:
>
> If EAPI is to be set, it must be set strictly before any global scope
> command or package manager defined function is called. Once set, EAPI
> must not be set to a different value.

...not quite weasely enough. Also needs:

and before any package manager defined variables are used or package
manager set shell behaviour is relied upon.

--
Ciaran McCreesh

On Thu, Feb 26, 2009 at 11:50 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 26 Feb 2009 18:07:32 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> There's a less extreme variant on this that's slightly cleaner, and
>> with appropriate weaseling is also less messy. Simply add the
>> following very carefully worded additional requirement for future
>> EAPIs, and retroactively impose it upon current ones:
>>
>> If EAPI is to be set, it must be set strictly before any global scope
>> command or package manager defined function is called. Once set, EAPI
>> must not be set to a different value.
>
> ...not quite weasely enough. Also needs:
>
> and before any package manager defined variables are used or package
> manager set shell behaviour is relied upon.
>

Is the following a stricter subset of your wording? --

"EAPI must be set in an ebuild as the first non-comment line, and
thereafter must not be set to a different value"

I'm asking because it would be simpler for users and devs to
understand, even if it is a subset.


--
~Nirbheek Chauhan

On Fri, 27 Feb 2009 00:17:36 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> Is the following a stricter subset of your wording? --
>
> "EAPI must be set in an ebuild as the first non-comment line, and
> thereafter must not be set to a different value"

No. With your wording, the following are legal:

EAPI=$(echo 1 )

EAPI=${PV}

EAPI=$( a=() ; a+=3 ; echo ${a[0]} )

--
Ciaran McCreesh

On Fri, Feb 27, 2009 at 12:26 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 27 Feb 2009 00:17:36 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> Is the following a stricter subset of your wording? --
>>
>> "EAPI must be set in an ebuild as the first non-comment line, and
>> thereafter must not be set to a different value"
>
> No. With your wording, the following are legal:
>
> * *EAPI=$(echo 1 )
>
> * *EAPI=${PV}
>
> * *EAPI=$( a=() ; a+=3 ; echo ${a[0]} )
>

Ah, I thought I might be missing something. Then how about:

"EAPI must be set in an ebuild as the first non-comment line, such
that bash does not perform any expansions during the assignment, and
thereafter must not be set to a different value"

of course, this is entirely documentation-oriented, and might be
bike-sheddery

--
~Nirbheek Chauhan

On Fri, 27 Feb 2009 00:46:04 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> Ah, I thought I might be missing something. Then how about:
>
> "EAPI must be set in an ebuild as the first non-comment line, such
> that bash does not perform any expansions during the assignment, and
> thereafter must not be set to a different value"

Close, but no banana. You've also got to specify that any syntax used
up to and including that line has to be bash-3 legal.

The problem is... If bash-5 introduces multi-line comments or a new
assignment syntax, your version doesn't forbid:

#* Copyright etc
more multiline stuff
*#

let EAPI = 3

Unfortunately, we have to care about these things when doing the formal
spec... There're developers who'll pull all kinds of insane crap in the
tree...

--
Ciaran McCreesh