[gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> 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

This is GLEP-55 I think, and it is my preference.  It seems to solve
the problem that the glep sets out to solve and has no effect on
current portage.    I don't claim that it's beautiful or perfect, but I
have not seen a better alternative, either.  It also has going for it
the fact that some number of people have already thought through it and
Piotr went to the effort of writing it up as a proposal, so it has had
more thought put into it than alternatives.  I do not find the
arguments against it persuasive, so I'd say do this and be done with
it.  We can argue forever for better alternatives, but I don't see that
we are getting very far with that approach.  Just my opinion, of course.

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

This one's OK with me, too, if people prefer it.

> 
> 3) EAPI in locked down place in the ebuild

I generally dislike this sort of thing, and I think it puts more of a
strain of the ebuild developers.  But then, I'm not an package
developer, so my opinion with respect to this is not worth much.  I'd
just rather see the EAPI visible in the file name than have to read the
ebuild to find it, and I guess the overhead argument is that it's
easier on portage not to have to do that, too.

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

I don't see why this is better than the glep 55 proposal???

>   b) new subdirectory like ebuilds/

Yuch.

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

Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> 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

#1

Though I also wouldn't mind separate EAPI and ebuild-format versions,
EAPI limited to the stuffing and EBV for the bird.  I'd expect the
number of times we'll need to make global changes will be few.
(fewer than EAPI changes anyways)

>   b) .<eapi>.ebuild
>     - current Portage does not work with this

#2

>   c) .<eapi>.<new extension>
>     - ignored by current Portage

This would be #2 if I could think of a better extension than .ebuild

.esh
.gentoo
.rebuild
.fbuild
.eawesomeness

(not seriously)

> 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

#3

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Richard Freeman]

Petteri Räty wrote:
> 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 don't see how this follows.  The PM can compare the mtime on the file 
with the time the cache was updated and refresh if needed.  Or we could 
require users to manually refresh the cache if they modify an ebuild.

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

I don't see how this follows.  You can put any version in the filename 
that you like just as with the EAPI in the filename approach.  A package 
manager won't process the filename if it doesn't understand the EAPI. 
The order of processing for a package manager would be:
1.  Scan for files named *.ebuild.
2.  Scan the nth line inside to obtain the EAPI.
3.  Take further action in accordance with the EAPI - possibly including 
obtaining the package name/version from the filename, or maybe somewhere 
else entirely.

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

Why wouldn't you cache every version of a package with its EAPI for 
reference?  I don't follow why this needs more cache hits.  However, 
even if you had to hit the cache more often I don't see why a cache 
lookup would be expensive.  Isn't it stored in a sensible format for 
rapid random access?

My preference is obviously for embedding the EAPI inside the file in 
some manner.  My second preference would be for only changing the file 
extension on rare occasions that are individually approved by the 
Council when things need to change dramatically, as opposed to any time 
the EAPI changes.

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Jeremy Olexa]

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
> 

Thanks for gathering input from the dev community. I do not wish to 
respond to the monster thread (and won't).

Personally, I don't need the flexibility that glep55 provides for *my* 
ebuilds. The current scheme doesn't bother me. And actually, after doing 
some testing, I found that at least one of that packages/projects that I 
am involved in will need updating every time the extension changes (or 
some more broad change - I don't have time to investigate too much tbh). 
So, I would prefer that the file extension did not change [much/every 
eapi]. However, I can roll with the punches if it truely is needed. I 
also understand that some change is good in the long run even if it has 
some upfront cost to it.

However, in case that this discussion gets deferred until later, I would 
like to express that the Council should "request" (not demand) that 
portage adds support for the leading 2 ideas that result from the 
current discussion. This will allow us to not wait even longer when we 
are having this discussion in 2010 (hypothetically).

Thanks for listening, Petteri.
-Jeremy

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Dawid Węgliński]

On Tuesday 24 of February 2009 23:21:23 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

All of this are ok for me, though the first shot is my preffered one since 
it's the most human readable and the rest would be mostly seen as the package 
version.

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

I don't see this as the best solution.

>   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

Nah. Scanning portage tree in this place would be more painful than it's 
currently.

>   c) .ebuild in current directory
>   - needs one year wait
>
> Regards,
> Petteri

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Alistair Bush]

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

Thank you Petteri. I knew there was a reason I voted for you.

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

a) then c).  I personally think b) is a bad idea that will just slow the
implementation of this even more.

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

If it really comes to it  b)?  Tho it leaves a bad taste in my mouth.

> 
> Regards,
> Petteri
> 

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Alec Warner]

> On Tue, Feb 24, 2009 at 2:21 PM, Petteri Räty <betelgeuse@gentoo.org> 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

I'm adding stuff to this; but its in my copy of glep-55.txt which I
will probably send out later.  I basically see this as a mix of
options and requirements and thats how I would expect the council to
make their decision.
For instance; if we don't care about backwards compatibility with
older managers than we can enable a number of other solutions that
would otherwise be excluded.  If we want to be able to swap versions
of bash as a requirement; that automatically excludes specific
solutions that don't handle that case.  So in my rewrite of glep55 I'm
attempting to make a list similar to yours and try to convey what
requirements are togglable for each thing.  In the end I expect the
council to:

 - Choose requirements that make the most sense for Gentoo.
 - Look at the solutions that are left that meet said requirements and pick one.

dev.gentoo.org/~antarus/projects/gleps/glep-0055.html for the updated GLEP.

-A

>
> Regards,
> Petteri
>
>

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Jeroen Roovers]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> Let's try something new. I would like to get opinions [...]

A multitude of leaves on every branch of the tree. That could be a
multiple of the current tree size - maybe talk to infra about this.

It's also a multitude of complexity - as an arch security liaison, I
get to see how difficult it is already to figure out which revision to
test and mark, and figuring out why a certain revision isn't ready yet
is tantamount to figuring out what EAPI=foo actually means.

As an ebuild developer I get to see how difficult it is to figure out
which EAPI is ready enough to write ebuilds for - Changing filename
extensions is to me like a Windows 95 way of opening a file and it
doesn't at all tell me what I can and cannot put into that file.

Either as an arch, or as ebuild dev pur sang, I don't care about EAPIs
that much until I want to use a new feature - I don't want to maintain
EAPI=N branches of testing and stabling systems to test stuff either
before it's published or when it's time for stabilisation. Stamping
EAPIs down in filename extensions is just another way to point out the
cruft.

As a bug wrangler, it doesn't solve current problems of stale overlays
with too novel or too old ebuilds.

To users, it doesn't matter at all - which seems to bring about the
question of the use case everyone's clamouring for. What developers
will benefit this at all, how large are the branches this will affect,
how many developers will have to rewrite tools, and so on?


Kind regards,
      jer

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ulrich Mueller]

>>>>> On Wed, 25 Feb 2009, 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.

I've already commented on this in December 2007 [1], and my opinion
hasn't changed.

> 1) Status quo
> 2) EAPI in file extension
> 3) EAPI in locked down place in the ebuild
>   a) <new extension>
>   b) new subdirectory like ebuilds/
>   c) .ebuild in current directory

Acceptable for me would be 1) and 3c).

>   - needs one year wait

Please state more precisely, what events would mark the beginning and
end of this time period?

Ulrich

[1] <http://archives.gentoo.org/gentoo-dev/msg_81b3eeb61186874caa291b66e728348c.xml>

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Joe Peterson]

Ulrich Mueller wrote:
>>>>>> On Wed, 25 Feb 2009, 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.
> 
> I've already commented on this in December 2007 [1], and my opinion
> hasn't changed.
> 
>> 1) Status quo
>> 2) EAPI in file extension
>> 3) EAPI in locked down place in the ebuild
>>   a) <new extension>
>>   b) new subdirectory like ebuilds/
>>   c) .ebuild in current directory
> 
> Acceptable for me would be 1) and 3c).

I have also stated my opinion before.  But I agree with Ulrich.

					-Joe

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

I have no strong opinion about this.

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

simple, straightforward but ugly

>   b) .<eapi>.ebuild
>     - current Portage does not work with this

this only has disadvantages in front of a)

>   c) .<eapi>.<new extension>
>     - ignored by current Portage

same as a) but maybe less ugly

> 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

This doesn't need a locked down place, just some strict way of setting
it, like at most one EAPI="constant_string_without_space" so that grep
& friends can catch it.

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

I'm not entirely sure about this and would need some real
example/argument in order to be convinced

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

true but this "more" would need to be measured and opposed to the
number of metadata loads in a dep resolution procedure.

>   a) <new extension>

doesn't have the one year wait drawback and doesn't mess with pm
implementation details (eapi) with package names that shall represent
upstream ones.

>   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

I see no advantage there vs 3.a)

>   c) .ebuild in current directory
>   - needs one year wait

That could have been done one year ago and would be done now; I think
it's still fine now because I don't expect major behavior changes in
the ebuild format within one year.

To summarize, I would retain 3.a as best solution, having the "usable
right now" advantage of current glep55 and keeping the ebuild's file
names (more or less) consistent with upstream ones.

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Tobias Klausmann]

Hi! 

My preference, most wanted to least wanted:

- inside the ebuild
  If it's not too much pain. Yes, that is a very subjective
  metric and it's what a large amount of flames has been about.

- in the filename, but not as a tail
  eg: foo-2.3.4-r2+9.build 
  yes, alternate separators might be better. 
  I like .build very much, though. What does the e in ebuild
  stand for anyway?

- in the filename, as a tail 
  eg: foo-2.3.4.ebuild-9
  I don't like this much, but it's better than never having EAPI
  versioning.


Regards,
Tobias
-- 
printk("Cool stuff's happening!\n")
        linux-2.4.3/fs/jffs/intrep.c

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Peter Alfredsen]

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> 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.
[...]

I dislike GLEP 55 aesthetically, but I see no other way to move out of
this deadlock where we can't use new bash-features till years have
passed. So unless someone suggests a solution that allows us to have
EAPI as part of the ebuild without having to wait till hell freezes
over, I'm behind GLEP 55 as the least-bad solution.

/loki_val

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Michael Haubenwallner]

On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote:
> get opinions [..] to get some idea what the general developer pool thinks.
> only allowed to post a single reply to this thread

Thank you for that, I usually don't follow long threads, so apologies if
things have been discussed already.

Basically, I'm all for having GLEP55 "as good as possible" in favour of
"as soon as possible" before implementation, even if it fits my
thoughts quite good already (see below).

> 2) EAPI in file extension

IMO, this should define *how* to read the *final* EAPI from the ebuild.
The *how* does not necessarily mean to /source/ the ebuild, so the terms
"pre-source EAPI" and "post-source EAPI" IMHO are too strongly focussing
on "(bash)> source $EBUILD" when used in a generic GLEP. Eventually, the
 "pre-source" EAPI could be called "major" EAPI, and the
"post-source" EAPI could be called "major.minor" EAPI (see below).

The "EAPI in file extension" also should define the filename-part of the
versioning rules.

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

"ignored by current portage" is an important point for me to
*theorethically* guarantee for a possible upgrade path even over long
time.

> 3) EAPI in locked down place in the ebuild

This "lock down" should be done by "EAPI in file extension" above.
"lock down" can mean any of: "post-source (real bash-source)",
"self-parse (grep?)", "fixed-byte/line-offset", "..."

My thoughts are to split EAPI into several levels (rename them however
you like):

entry-point:
        Specifies how to read the "filename-scope" EAPI.

filename-scope EAPI:
        Think as "major" EAPI.
        Specifies the filename-part of versioning rules.
        Specifies how to read the "global-scope" EAPI (can, but
        eventually should not require bash-sourcing the ebuild).
        May allow to not define "minor", assuming "$major.0.0" then.
        
global-scope EAPI:
        Think as "$major.minor" EAPI.
        May specify how to define additional versioning rules.
        Specifies how to define metadata information.
        Specifies which metadata information is
        required/optional/cached/... Specifies how to utilize external
        resources (eclasses).
        Specifies which/how actions can/must be defined (pkg_*, src_*
        functions).
        Specifies how to read the "local-scope" EAPI.
        May allow to not define "micro", assuming "$major.$minor.0"
        then.
        May disallow a "local-scope" EAPI, specifies it instead.
        
local-scope EAPI:
        Think as "$major.$minor.micro" EAPI.
        Specifies which PM-functions are available for use in actions
        (fex 'doman' inside src_install).
        May be specified as part of "minor" EAPI.

Thanks!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Mike Auty]

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

Petteri Räty wrote:
> 3) EAPI in locked down place in the ebuild
>   c) .ebuild in current directory
>   - needs one year wait

I'm all for 1 or 3c, because we're not in any rush.

I don't see why there's such an immediate need to make as drastic
changes as are being suggested for GLEP-55, simply to allow for the
possibility of future unknown ebuild mechanisms (like ebuilds not being
bash scripts).  If ebuilds change significantly from their current form,
then and only then, would it be a good time to change the ebuild suffixes.

I don't want to get an attachment from bugzilla and find I have to try
four different file extensions because whilst the package and version
were obvious from the bug, the eapi number wasn't.

I also don't want to run into a situation where this package manager
supports kdebuilds, whilst that package manager supports gnomebuilds,
and a third one supports xfcebuilds.  That's just recreating the browser
wars, and will leave us with the likes of IE6.

I'd be relatively happy with a shebang that specifies the parser or
passes the ebuild version, as long as it was standardized, linear and
supported by all the PMs (ie, some rogue PM can't suddenly start
allowing a "myeapi" that only it can build)...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmlKQEACgkQu7rWomwgFXoRFACdHfDHuHhj7ojsQV5FvF+rRpRT
PgQAoKTq6iAmNLC50a97JHrQghRZK6O0
=ELuP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Jim Ramsay]

Petteri Räty <betelgeuse@gentoo.org> wrote:
> 2) EAPI in file extension
>   - Allows changing global scope and the internal format of the ebuild
>   a) .ebuild-<eapi>
>     - ignored by current Portage
>   c) .<eapi>.<new extension>
>     - ignored by current Portage

Any of the above are fine with me, there is a demonstrated need for
this to introduce changes that current portage could not handle.

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

3.a is just like glep-55, except that the filename extension doesn't
change all the time.  I like that this will have the benefits of
glep-55 plus the benefits of making happy the people who don't want the
EAPI in the filename or the extension to change very often.

This will effectively change a single EAPI number into a major/minor
pair.  The major part (the extension name) would only ever change when
a major feature is introduced that breaks the current portage rules.
The internal EAPI, specified however we like in the major format
specification, could be in a fixed location or otherwise easily
parseable.  Then small changes would alter this minor/internal EAPI
value.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]

On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty 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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Andrew Gaffney]

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

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Wed, 25 Feb 2009 04:49:51 -0800
Brian Harring <ferringb@gmail.com> wrote:
> 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as 
>  the first statement (simplest way).

Doesn't solve anything over having it as a variable, and has a messy
upgrade path.

>   - global scope changes can occur (inherit mechanism changes 
>     included).

Global scope changes can no more occur than they can with it as a
variable. All it does is changes where the barfing occurs to slightly
earlier on.

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

Global scope die is very very messy. This leaks out to users in the
form of horrible messages that make the user think something's badly
broken.

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

Unportable, and still leaks out to users.

This whole thing only looks neat until you think about it...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

On Wed, Feb 25, 2009 at 11:03:07PM +0000, Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 04:49:51 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as 
> >  the first statement (simplest way).
> 
> Doesn't solve anything over having it as a variable, and has a messy
> upgrade path.
> 
> >   - global scope changes can occur (inherit mechanism changes 
> >     included).
> 
> Global scope changes can no more occur than they can with it as a
> variable. All it does is changes where the barfing occurs to slightly
> earlier on.

Bullshit.  First invocation of the ebuild, that means it can do 
whatever it wants to the environment- literally swapping in the EAPI 
environment right then/there.  Auto inherits, changing the inherit 
mechanism, everything (this includes shopt adjustments).

Not even sure why you're arguing that one, but back it up w/ examples 
if you want to continue that line of FUD.


> >   - 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)
> 
> Global scope die is very very messy. This leaks out to users in the
> form of horrible messages that make the user think something's badly
> broken.

One would think "upgrade your manager" would be... self explanatory.  
Regardless, spelling it out- the user visible barf is only visible on 
existant managers.

For any manager supporting eapi>2 (thus having the function), the 
function can exist out cleanly (no stderr complaints) from sourcing at 
that point without issue.


> >    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).
> 
> Unportable, and still leaks out to users.

Two options were given there; one 'leaks out to users', the other is 
the old behaviour (eapi env setting)- again, this is only visible for 
the window of pre eapi 3 managers, meaning it's a one time hit (rather 
then continual as you're implying).


Every proposal has uglyness- g55 for example doesn't give the user any 
indication that they're not seeing ebuilds due to EAPI (in other words 
loss of functionality that exists now).

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On Wed, 25 Feb 2009 16:02:46 -0800
Brian Harring <ferringb@gmail.com> wrote:
> Bullshit.  First invocation of the ebuild, that means it can do 
> whatever it wants to the environment- literally swapping in the EAPI 
> environment right then/there.  Auto inherits, changing the inherit 
> mechanism, everything (this includes shopt adjustments).
> 
> Not even sure why you're arguing that one, but back it up w/ examples 
> if you want to continue that line of FUD.

You can do that on a variable assignment too, with all the same
implications as having it as a function, and a slightly less horrible
upgrade path.

> > Global scope die is very very messy. This leaks out to users in the
> > form of horrible messages that make the user think something's badly
> > broken.
> 
> One would think "upgrade your manager" would be... self explanatory.  
> Regardless, spelling it out- the user visible barf is only visible on 
> existant managers.
> 
> For any manager supporting eapi>2 (thus having the function), the 
> function can exist out cleanly (no stderr complaints) from sourcing
> at that point without issue.

Which is a "wait a year or more" thing... If you do it with a variable
instead of a function, you can at least roll out EAPI 3 (without any
global scope changes, but with the stricter "stop on setting an
unsupported EAPI" requirement) without the wait.

> Every proposal has uglyness- g55 for example doesn't give the user
> any indication that they're not seeing ebuilds due to EAPI (in other
> words loss of functionality that exists now).

Given you're a proponent of not showing users things that're merely
masked...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

On Thu, Feb 26, 2009 at 12:11:04AM +0000, Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 16:02:46 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > Bullshit.  First invocation of the ebuild, that means it can do 
> > whatever it wants to the environment- literally swapping in the EAPI 
> > environment right then/there.  Auto inherits, changing the inherit 
> > mechanism, everything (this includes shopt adjustments).
> > 
> > Not even sure why you're arguing that one, but back it up w/ examples 
> > if you want to continue that line of FUD.
> 
> You can do that on a variable assignment too, with all the same
> implications as having it as a function, and a slightly less horrible
> upgrade path.

You're contradicting your own statements.  Pkg level eclasses (if 
reusing inherit) would explode 'in a user visible manner' if using var 
only.

While the above wasn't FUD, definitely was misinfo.  Be consistant 
please.


> > > Global scope die is very very messy. This leaks out to users in the
> > > form of horrible messages that make the user think something's badly
> > > broken.
> > 
> > One would think "upgrade your manager" would be... self explanatory.  
> > Regardless, spelling it out- the user visible barf is only visible on 
> > existant managers.
> > 
> > For any manager supporting eapi>2 (thus having the function), the 
> > function can exist out cleanly (no stderr complaints) from sourcing
> > at that point without issue.
> 
> Which is a "wait a year or more" thing... If you do it with a variable
> instead of a function, you can at least roll out EAPI 3 (without any
> global scope changes, but with the stricter "stop on setting an
> unsupported EAPI" requirement) without the wait.

There is no reason to wait a year let alone wait for EAPI3 to be 
defined.  The eapi function could be added now in preparation (thus 
killing the user visible pukage), regardless of eapi 3's timeline.

The die exists strictly to be thorough about stragglers.


> > Every proposal has uglyness- g55 for example doesn't give the user
> > any indication that they're not seeing ebuilds due to EAPI (in other
> > words loss of functionality that exists now).
> 
> Given you're a proponent of not showing users things that're merely
> masked...

Say what you want; g55 still has the flaw.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

On Wed, 25 Feb 2009 16:24:45 -0800
Brian Harring <ferringb@gmail.com> wrote:
> > You can do that on a variable assignment too, with all the same
> > implications as having it as a function, and a slightly less
> > horrible upgrade path.
> 
> You're contradicting your own statements.  Pkg level eclasses (if 
> reusing inherit) would explode 'in a user visible manner' if using
> var only.

No, if we're shoving retroactive changes into existing EAPIs (as would
be done for making eapi a function), we could instead say "EAPI must be
assigned to only once". That has *exactly* the same implications as
having it as a function, except that the upgrade path is cleaner
because there's no need for the horrid global scope die to work around
existing package managers.

> > Which is a "wait a year or more" thing... If you do it with a
> > variable instead of a function, you can at least roll out EAPI 3
> > (without any global scope changes, but with the stricter "stop on
> > setting an unsupported EAPI" requirement) without the wait.
> 
> There is no reason to wait a year let alone wait for EAPI3 to be 
> defined.  The eapi function could be added now in preparation (thus 
> killing the user visible pukage), regardless of eapi 3's timeline.
> 
> The die exists strictly to be thorough about stragglers.

But there's no need for the die if you do it on a variable instead of a
function.

> > > Every proposal has uglyness- g55 for example doesn't give the user
> > > any indication that they're not seeing ebuilds due to EAPI (in
> > > other words loss of functionality that exists now).
> > 
> > Given you're a proponent of not showing users things that're merely
> > masked...
> 
> Say what you want; g55 still has the flaw.

Any sane package manager can, immediately upon a new EAPI being
defined, do a stable release updated with minimal information about the
new EAPI to enable it to show up as being there but not supported, even
if full support needs a new major version and lots of ~arch testing
time.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Jorge Manuel B. S. Vicetto]

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

Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 16:02:46 -0800
> Brian Harring <ferringb@gmail.com> wrote:
< snip a few arguments>

Ciaran and Brian,

please respect Pettery's request and move your discussion to the GLEP55
thread or to another thread, but leave it out of this one.

Ciaran,

please stop abusing other subscribers of the dev ml.
Ultimately everyone wants a resolution to this "issue" but have
potentially different ideas of the way to go about that. So different
ideas for a solution should be encouraged, not fought.
You're obviously free to argue your case and I'm not trying to silence
you, but by replying to every and single mail in quite a few cases in a
harsh tone, you're behaving like a "bully". Please stop that.
For anyone else acting overly defensive, please remember that these are
technical discussions, so you should expect technical arguments and
having your ideas challenged. Also, everyone should be careful not to
let emotions affect their arguments.

For userrel,

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkml5cAACgkQcAWygvVEyAKrmgCfZK4wpk0+PcZPCftsAyloEhDK
4DkAoJGspbLcPYb0f+FkZqVgb/kGWYhU
=SSGP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Wed, 25 Feb 2009 23:43:44 -0100
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 25 Feb 2009 16:02:46 -0800
> > Brian Harring <ferringb@gmail.com> wrote:
> < snip a few arguments>
> 
> Ciaran and Brian,
> 
> please respect Pettery's request and move your discussion to the
> GLEP55 thread or to another thread, but leave it out of this one.

This was moved to another thread, as a casual glance at the subject
would have told you.

> please stop abusing other subscribers of the dev ml.
> Ultimately everyone wants a resolution to this "issue" but have
> potentially different ideas of the way to go about that. So different
> ideas for a solution should be encouraged, not fought.
> You're obviously free to argue your case and I'm not trying to silence
> you, but by replying to every and single mail in quite a few cases in
> a harsh tone, you're behaving like a "bully". Please stop that.

One of the nice things about technical discussions is that it is
entirely possible for one particular party to be entirely wrong. In
this case, Brian is entirely wrong, and calling him on it is the
correct thing to do.

If you would prefer to see fewer emails from me, perhaps you should
start telling people who post the same incorrect claims that have
already been demonstrated to be false over and over again to stop it.
One of the unfortunate tendencies the Council has shown in the past is
to treat any unreplied-to objection as being legitimate and cause for
an issue to be postponed, even if that issue has already been addressed
earlier on.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 23:43:44 -0100
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Wed, 25 Feb 2009 16:02:46 -0800
>>> Brian Harring <ferringb@gmail.com> wrote:
>> < snip a few arguments>
>>
>> Ciaran and Brian,
>>
>> please respect Pettery's request and move your discussion to the
>> GLEP55 thread or to another thread, but leave it out of this one.
> 
> This was moved to another thread, as a casual glance at the subject
> would have told you.
> 

The In-Reply-To/References headers in your reply makes at least
Thunderbird put it to the same thread as my the original thread.
Probably similar logic exists in other email clients too. This means
that when using these clients this thread shows in the middle of the
opinion thread so please let's put all further replies elsewhere.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Tuesday 24 February 2009, 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.

Thanks for opening a spot to voice our opinions within reasonable limits 
and without deadlocked discussions.

To make it brief, I'd very much prefer 3c[0] for the reasons provided by 
others before:
- From what I can see, it provides for all requirements set out by g55.
- There is a backwards-compatible way to implement it.
- It does not expose any more internal metadata than current ebuilds do.
- I see no rush to implement new EAPI features that require drastic
  changes enabled by 1*.
- It provides a constant face for Gentoo, aka we're the guys and gals 
  using the ".ebuild" format.


Robert

[0] Although not with a fixed line limit, but with a strict way to find
    it, i.e. the first occurence of #?\s*EAPI=["']?([a-zA-Z0-9._]+)["']?   
    or similar.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
> 1) Status quo
>   - does not allow changing inherit
>   - bash version in global scope
>   - global scope in general is quite locked down

Yuck, I want per-package eclasses and all those other goodies.

> 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

2a please, though .ebuild.eapi would be fine as well. My reasons are
mostly contained in Antarus' glep revision, and the fact that there have
been no real valid(IMO) objections.

> 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

These are all ugly.(c is the worst).

Oh, And I certainly hope this is not Democracy(you know what they say,
democracy is two wolves and a sheep deciding who to have for dinner)

Looking forward to the council meeting, where there will *hopefully* be
a decision.

Thomas
-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

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

> 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

Leave EAPI inside the ebuild. That's where I want to find it.

Oh, and as others have mentioned, CVS sucks for file renaming and
versions. Yet another reason to leave it inside the ebuild.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ravi Pinjala]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Kumba]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Kumba]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Zac Medico]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Nirbheek Chauhan]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Nirbheek Chauhan]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Caleb Cushing]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Rémi Cardona]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Peter Volkov]

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.

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Robert Bridge]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

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.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Thilo Bangert]

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

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Jacob Floyd]

Hello all,

Here are my comments, opinions, and a recommendation regarding "GLEP
55" and similar proposals. I've put in 1) A) and a) numbering to
differentiate the various lists. Though perhaps long winded, at least
check out the Recommendation below.

The idea of sticking EAPI in metadata.xml was opposed because of XML
overhead, and it's a general purpose file, whereas this would force it
to have versioned info. Makes sense to me. Though that was one of the
ideas I was toying with because the EAPI really is metadata.

===== Extension =====
I don't like the idea of changing the extension because (in part
summarizing what some others have said):

1) inconsistency is not good (rh/fedora has always been .rpm, debian
has had .deb, gentoo has .ebuild) That's also why we prefer tabs over
spaces and ordering the variables uniformly (at least on sunrise).
It's a consistency issue.

2) If you change the extension, it becomes technically more difficult
to prevent multiple versions of the same package, thus users probably
will be required to start specifieing an EAPI when they want to merge
a package, because several devs, perhaps on overlays, will start
providing multiple versions of ebuilds in different EAPI.

3) #2 brings GLSA into play - Changes may have to be made in packages
implementing a variety of eapis creating a greater burden to see what
the difference is between these different ebuilds.

4) If portage does enforce the single eapi per version, that creates
an even bigger problem for other "package managers" which was a
problem that this GLEP was trying to address, but ends up making
smooth interop even more difficult. Some PMS will support multiple
EAPIs and others will say no... Overlays...

5) Version bumps are more difficult as you have to worry about the
eapi in the file name

6) If GLEP 55 goes in without GLEP 60, you may need to add a new key
in the Manifest for each new EAPI: EBUILD-1 EBUILD-2 EAPI-2-EBUILD...
(or something like that) As it is it's just EBUILD. If/when GLEP 60
goes in as well, then you have the issue of, "we changed the name -
it's no longer an ebuild, but the manifest says it is" which might be
a tad confusing (and inconsistent)

===== In Ebuild =====
The idea of leaving EAPI defined in the ebuild has the following setbacks:

A) sourcing the ebuild to discover the EAPI enforces a strict global
part, which prevents significant changes to inherit amongst other
things

B) It could break as we migrate to newer versions of bash or perhaps
"ebuilds" or equivalents that might be in another language (who knows)

C) Having a spot locked down in an ebuild to search for EAPI brings a
migration drawback, as current ebuilds have something else on line 4
or line 5 or whatever, and a potentially erroneous value could be
returned for EAPI

D) Sourcing the ebuild twice brings a lot of overhead significantly
slowing an already (many times) slow process (especially when you
imagine KDE and other packages that take a while to compile - 6
seconds extra for each package - *shiver*). And it's ugly to have to
do it twice.

E) EAPI really is metadata and doesn't should be accessible before
sourcing the ebuild.

===== Recommendation =====
OK. Now for a slightly different solution, or a twist on the other
solutions if you will:

Stick EAPI info in the Manifest. The Manifest stores metadata info
about the ebuilds for security and validation purposes, why not add a
string that determines which eapi to use? This then would be generated
every time someone did an "ebuild foo-1.0.ebuild digest". To specify
the eapi version, the developer would specify, as is now, EAPI="bla"
in his ebuild, and grep or similar would be used to extract this when
the digest is created. The above mentioned points compare with this
solution (as I see it) as follows:

-1) Preserves .ebuild allowing for changes if a move were ever made to
some other format (who knows: python, or
some-cool-new-script-that-beats-bash-by-a-long-shot)
-2) Does not change the extension
-3) Ditto
-4) Ditto
-5) Version bumps might take a fractoin longer, as an additional grep
is added to the digest process... but arch maintainers shouldn't have
a problem with that. (I'm not an arch maintainer, mind you. I'm not
even @g.o)
-6) This takes care of any Manifest issue, because eapi'll be defined
to start off with in the Manifest in a uniform manner

-A) No need to source the ebuild twice, just grab the variable from
the manifest in the normal execution of digest verification. However
if the digest is wrong, or the Manifest doesn't exist or whatever,
that is an error and error handling will need to be introduced to grep
the EAPI at this point if regenerating the digest is needed/requested
-B) A new EAPI would be introduced for such "new" versions of bash and
if there were other formats (as in, not bash) they really should get
their own extension anyway, but we need some uniform way to grep it
and grab the info, or if it can't be found assume that it's EAPI 0
-C) It wouldn't have to be on a specific line, though no logic could
be used to determine the EAPI (eg no: if use bla; then EAPI="bla"; fi)
But it's not used that way right now anyway.
-D) This removes the overhead issues of leaving it in the ebuild.
-E) The dev specifies it in their ebuild, but it's put in the Manifest
where metadata about ebuilds belongs.

Now, as far as mitigating migration issues with old PMS that want to
use the old inherit, let them =) :

### Imaginary ebuild snippet ###
EAPI="NewFoo"
inherit eapi
inherit2 eutils mypkg.local whatever
new_func() {
       #and other stuff that isn't in eapi 0-2 only in the fancy
"NewFoo" EAPI I just invented.
       if pig and oink; then ewarn "You're in a barnyard, watch your
step! If flames went up, this list wouldn't like it."; fi
}
new_func pig oink
### Imaginary ebuild snippet ###

===== Explanation =====
Create a new eapi.eclass that smoothes migration.

a) You can have it eerror or ewarn or something to let the user know
they need to upgrade to a new version of portage, or file a bug report
with their PMS to support the new EAPI ${EAPI} that is used by this
package.

b) Such an eclass can implement a bogus inherit2 which would allow
older PMS to at least sort of finish sourcing the ebuild.

c) it could die gracefully on known problematic PMS (yes, a die in the
global scope - but it would be the one exception in the entire portage
tree - ebuilds still would not be allowed to put die in the global
scope, and pre-"inherit eapi" (not pre-inherit2) lines in the ebuild
would still have to conform to EAPI 0 specs, but everything after that
point would be the new eapi spec.

d) It's a graceful stop-gap to help relieve stress due to users not
upgrading in 2 or 3 years or whatever might happen, it'll give them a
smoother upgrade path.

e) at some point when it's determined that users don't need such an
eclass anymore, nearly everyone has upgraded or whatever, the eclass
could be changed/removed/whatever/I don't know. But until such a
point, would include placeholder functions for new "functions"
unimplemented in older PMS.

f) if an eapi implements features in the global scope that are
drastically different from one eapi to the other, the function could
simply put a DEPEND on the newer portage version, and display a
message that portage will be updated and then they'll need to
re-emerge the package, or something like that.


inherit2 would be a new fangled inherit can do whatever you want, and
would be an dev-opt in type thing, the original inherit could, in
theory, be used to inherit other eclasses, but those eclasses would
also be restricted to EAPI 0 (or EAPI 1, 2 with proper "if [[ ${EAPI}"
sniffing) specs, wheras ebuilds in inherit2 would not have that
restriction and could use the newfangled features.


Anyway, there's my 2 cents. What do you all think?
Jacob Floyd
(on irc in some channels: techgurufloyd)

[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Duncan]

Jacob Floyd <techgurufloyd+gentoo.lists@gmail.com> posted
4afbebfe0903090601r5759177bt98639c0c3a61b894@mail.gmail.com, excerpted
below, on  Mon, 09 Mar 2009 07:01:21 -0600:

> Stick EAPI info in the Manifest. The Manifest stores metadata info about
> the ebuilds for security and validation purposes, why not add a string
> that determines which eapi to use? This then would be generated every
> time someone did an "ebuild foo-1.0.ebuild digest". To specify the eapi
> version, the developer would specify, as is now, EAPI="bla" in his
> ebuild, and grep or similar would be used to extract this when the
> digest is created.

So ultimately, you leave it in the ebuild, but duplicate it in the 
manifest... which has its own problems, one of which is that it 
ultimately falls back to getting the info from the ebuild so it has the 
same problems that does.

The problem with getting EAPI from the ebuild is that as currently speced 
in PMS, EAPI cannot be grepped, the ebuild must really be sourced to get 
it, because it may be changed in eclasses or set and repeatedly changed, 
etc.  And that doesn't really work going forward, because you end up 
needing to know the EAPI in ordered to source the ebuild properly to get 
it.  (It has only worked thus far because changes have been restricted to 
ensure it DOES still work, but that's not practical going forward as it 
really IS restrictive.)

By the time you fix that, you're back at one of the other 
implementations, effectively decreeing that the EAPI once set (or the 
EAPI major version, at least, in a major/minor EAPI versioning variant 
proposal) can't change and putting it either in the ebuild name/
extension, or in a location sufficiently nailed down in the ebuild that 
it can be scanned directly, line X, or whatever, or at /minimum/ 
narrowing the spec so that it must be early in the ebuild, before 
inherits, etc (there's a series of post by CiaranM with way more 
technical detail on exactly how the new requirement would have to be 
worded).

So putting it in the manifest but generated from the ebuild info really 
doesn't change the problem, leaving us precisely where we were before, 
except that it may be useful as a component of one of the other 
solutions, and has been proposed as such in a few of the suggested 
variants.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Richard Freeman]

Duncan wrote:
> So putting it in the manifest but generated from the ebuild info really 
> doesn't change the problem, leaving us precisely where we were before, 
> except that it may be useful as a component of one of the other 
> solutions, and has been proposed as such in a few of the suggested 
> variants.
> 

I think that it does address ONE aspect of the limitations of putting 
EAPI in the build - but not all.

One issue with EAPI in the build is figuring out what it is without 
sourcing the ebuild (possibly using a package manager that doesn't 
realize that it doesn't know how to source it).

If the developer of an ebuild prepares the manifest, then at least their 
package manager will know how to handle the ebuild and extract the EAPI. 
  Now, that could still be messy if it needs to source the ebuild 3 ways 
before finding the one that delivers the correct EAPI.  However, 
end-user package managers wouldn't need to source the ebuild to figure 
out the EAPI.

Potentially the developer could just manually put the EAPI in the 
manifest (or use a tool to do this).  Obviously this is an extra step 
when adding ebuilds to the tree, but that would completely address the 
issues with sourcing builds.

Changing the manifest format of course creates backwards compatibility 
issues.

So, I wouldn't dismiss this idea out of hand - it isn't completely 
equivalent to the other options.

[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Duncan]

Richard Freeman <rich0@gentoo.org> posted 49B57409.5050406@gentoo.org,
excerpted below, on  Mon, 09 Mar 2009 15:54:49 -0400:

> If the developer of an ebuild prepares the manifest, then at least their
> package manager will know how to handle the ebuild and extract the EAPI.

Good point.  The dev's PM will presumably be updated to whatever EAPI 
he's committing, even if they user's isn't.  That does help some.

> However, end-user package managers wouldn't need to source the ebuild
> to figure out the EAPI.

If I've been paying attention, that isn't necessarily the case.  Ciaran 
can better answer why than I can, however.

> Potentially the developer could just manually put the EAPI in the
> manifest (or use a tool to do this).  Obviously this is an extra step
> when adding ebuilds to the tree, but that would completely address the
> issues with sourcing builds.

That's an interesting idea.  A "manual" method for putting the EAPI in 
the manifest, thus bypassing the chicken/egg issue of needing to need the 
EAPI to source the ebuild... to get the EAPI.

> Changing the manifest format of course creates backwards compatibility
> issues.

That's likely the biggest issue, potentially making this a "wait a year" 
solution.  But if we got in the PMs and started the clock now...

> So, I wouldn't dismiss this idea out of hand - it isn't completely
> equivalent to the other options.

True.  It may well be one component of a full solution, even if it 
doesn't on its own provide a full solution.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Hi,

Duncan <1i5t5.duncan@cox.net>:
> > Potentially the developer could just manually put the EAPI in the
> > manifest (or use a tool to do this).  Obviously this is an extra
> > step when adding ebuilds to the tree, but that would completely
> > address the issues with sourcing builds.
> 
> That's an interesting idea.  A "manual" method for putting the EAPI
> in the manifest, thus bypassing the chicken/egg issue of needing to
> need the EAPI to source the ebuild... to get the EAPI.

 Having the EAPI stored outside the ebuild's scope is generally a bad
idea, because someone has to tell you that the ebuild you just
downloaded from Bugzilla is EAPI x.  And the package manager will be
totally confused when assuming an EAPI that is wrong.  So the EAPI
should be stored inside (best solution regarding giving ebuilds away)
or in the file name (best compromise regarding the whole situation.

V-Li

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives

[Santiago M. Mola]

On Tue, Mar 10, 2009 at 4:58 PM, Christian Faulhammer <fauli@gentoo.org> wrote:
>
>  Having the EAPI stored outside the ebuild's scope is generally a bad
> idea, because someone has to tell you that the ebuild you just
> downloaded from Bugzilla is EAPI x.  And the package manager will be
> totally confused when assuming an EAPI that is wrong.  So the EAPI
> should be stored inside (best solution regarding giving ebuilds away)
> or in the file name (best compromise regarding the whole situation.
>

Most ebuilds in Bugzilla have a proper name. I suggest you to download
them with pybugz:
$ bugz attachment <ATTACHMENT-ID>
that will download it with the proper name.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Michael Haubenwallner]

Hi,

Reminder (for myself):
As long as we want/have to support PMs lacking EAPI detection in
'*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
to an '*.ebuild' must be hackish. So we can try to find the least ugly
hack, or we need to change the extension.

So just another idea, based on the "eapi() function" one:
As inherit() is the only(?) global function provided by old PMs, the
first non-commentary/non-blank line in '*.ebuild' could read:

   inherit eapi

Compliant PMs identify 'eapi' as a special eclass name (with or without
sourcing the ebuild), to know that "this ebuild specifies an EAPI".

For non-compliant PMs, we need to provide an 'eapi.eclass', which just
spits some 'your PM lacks EAPI support' message and causes the PM to
mask this ebuild 'by corruption' or the like.

Or - what are old PM's messages when an eclass is missing?

Eventually, this line also could finally specify the EAPI and read:

   inherit eapi 4

Because non-compliant PM's already quit because of (missing or dying)
eapi.eclass, there is no need to have a '4.eclass'.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Alistair Bush]

Michael Haubenwallner wrote:
> Hi,
> 
> Reminder (for myself):
> As long as we want/have to support PMs lacking EAPI detection in
> '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
> to an '*.ebuild' must be hackish. So we can try to find the least ugly
> hack, or we need to change the extension.
> 
> So just another idea, based on the "eapi() function" one:
> As inherit() is the only(?) global function provided by old PMs, the
> first non-commentary/non-blank line in '*.ebuild' could read:
> 
>    inherit eapi
> 
> Compliant PMs identify 'eapi' as a special eclass name (with or without
> sourcing the ebuild), to know that "this ebuild specifies an EAPI".
> 
> For non-compliant PMs, we need to provide an 'eapi.eclass', which just
> spits some 'your PM lacks EAPI support' message and causes the PM to
> mask this ebuild 'by corruption' or the like.
> 
> Or - what are old PM's messages when an eclass is missing?
> 
> Eventually, this line also could finally specify the EAPI and read:
> 
>    inherit eapi 4
> 
> Because non-compliant PM's already quit because of (missing or dying)
> eapi.eclass, there is no need to have a '4.eclass'.

How would the 4.eclass determine whether the package manager actually 
supports the eapi?

inherit is a function remember so any "special" parsing will not change 
the fact the the inherit function will be called.
Will then need to determine whether there is actually a PM that doesn't 
support the eclasses EAPI and then die.
What are the implications of calling inherit multiple times within an 
ebuild?

Im sorry,  but this just sounds like a HACK, and a hacky hack at that.

> 
> /haubi/

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Michael Haubenwallner]

(trying to have people understand the idea, not to discuss in this
thread)

On Fri, 2009-03-13 at 06:18 +1300, Alistair Bush wrote:

> > As long as we want/have to support PMs lacking EAPI detection in
> > '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI
> > to an '*.ebuild' must be hackish. So we can try to find the least ugly
> > hack, or we need to change the extension.

> >    inherit eapi 4
> > 
> > Because non-compliant PM's already quit because of (missing or dying)
> > eapi.eclass, there is no need to have a '4.eclass'.
> 
> How would the 4.eclass determine whether the package manager actually 
> supports the eapi?
> 
> inherit is a function remember so any "special" parsing will not change 
> the fact the the inherit function will be called.
> Will then need to determine whether there is actually a PM that doesn't 
> support the eclasses EAPI and then die.

The most important point here I thought everyone is aware of:
inherit() is a function provided *by* PM - or am I wrong here?

So it already *knows* to handle the 'eapi' argument as special when the
PM is compliant, to not read *any* eclass for this one inherit-call when
the ebuild gets sourced (assuming selected eapi specifies to
shell-source the ebuild).
And non-compliant PMs would mask the ebuild 'by corruption', because of
either missing or globalscope-dying eapi.eclass, whatever can be made
look more obvious to the user.

> What are the implications of calling inherit multiple times within an 
> ebuild?

A compliant PM does allow this if the selected eapi specifies to inherit
eclasses, a non-compliant PM will not come to a subsequent inherit call
after 'inherit eapi'.

> Im sorry,  but this just sounds like a HACK, and a hacky hack at that.

Agreed (see above).
Again - the only reason for this idea is to eventually allow for keeping
the '.ebuild' extension, because EAPI 0 does not allow for specifying
*any* eapi at all. It just forces PM to provide inherit() as the only
PM-defined global-scope function. So whatever we try, specifying an eapi
inside an .ebuild *without* changing the extension *will* be a hack,
just more ore less ugly.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level