[gentoo-dev] RFC: Place of EAPI variable in ebuild

[gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 282 bytes --]

Usually it's best that ebuild variables follow the order that is in
skel.ebuild. So know we should decide where to place EAPI. I suggest we
put it it after LICENSE as that's where the more technical stuff like
SLOT starts. Attached a patch for skel.ebuild.

Regards,
Petteri

[-- Attachment #1.2: eapi-location.patch --]
[-- Type: text/plain, Size: 700 bytes --]

Index: skel.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/skel.ebuild,v
retrieving revision 1.42
diff -u -r1.42 skel.ebuild
--- skel.ebuild	1 Jan 2007 12:18:17 -0000	1.42
+++ skel.ebuild	9 Nov 2007 21:55:43 -0000
@@ -40,6 +40,10 @@
 # docs on gentoo.org for details.
 LICENSE=""
 
+# The EAPI variable tells the ebuild format in use.
+# Defaults to 0 if not specified. See current PMS draft for more details.
+EAPI=1
+
 # The SLOT variable is used to tell Portage if it's OK to keep multiple
 # versions of the same package installed at the same time.  For example,
 # if we have a libfoo-1.2.2 and libfoo-1.3.2 (which is not compatible

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Fri, 09 Nov 2007 23:55:51 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Usually it's best that ebuild variables follow the order that is in
> skel.ebuild. So know we should decide where to place EAPI. I suggest
> we put it it after LICENSE as that's where the more technical stuff
> like SLOT starts. Attached a patch for skel.ebuild.

It needs to go right at the top, before 'inherit'.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Fri, 09 Nov 2007 23:55:51 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>> Usually it's best that ebuild variables follow the order that is in
>> skel.ebuild. So know we should decide where to place EAPI. I suggest
>> we put it it after LICENSE as that's where the more technical stuff
>> like SLOT starts. Attached a patch for skel.ebuild.
> 
> It needs to go right at the top, before 'inherit'.
> 

What if I want to use EAPI=1 features in an eclass? So if we for example
we have an ebuild using EAPI=2 and then it inherits and eclass that sets
EAPI=1 for slot deps.

Regards,
Petteri


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

[gentoo-dev] Re: RFC: Place of EAPI variable in ebuild

[Markus Ullmann]

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

> What if I want to use EAPI=1 features in an eclass? So if we for example
> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
> EAPI=1 for slot deps.

shouldn't be an issue as eapi 1 and 2 would have slot deps
though for other things like src functions defined in the eclass this
might become really interesting, especially if we get src_configure in eapi2

Greetz
Jokey


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

Re: [gentoo-dev] Re: RFC: Place of EAPI variable in ebuild

[Petteri Räty]

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

Markus Ullmann kirjoitti:
>> What if I want to use EAPI=1 features in an eclass? So if we for example
>> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
>> EAPI=1 for slot deps.
> 
> shouldn't be an issue as eapi 1 and 2 would have slot deps
> though for other things like src functions defined in the eclass this
> might become really interesting, especially if we get src_configure in eapi2
> 
> Greetz
> Jokey
> 

You didn't get my point. Unless inherit has some EAPI handling logic
setting EAPI in an eclass would overwrite the one in the ebuild.

Regards,
Petteri


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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Carsten Lohrke]

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

On Freitag, 9. November 2007, Petteri Räty wrote:
> What if I want to use EAPI=1 features in an eclass? So if we for example
> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
> EAPI=1 for slot deps.

You check which EAPI the ebuild sets, then either continue or die. Handling 
depends a bit upon, if EAPI should always be downwards compatible. Ideally 
only unset EAPI (for trivial ebuilds) and same EAPI would be allowed 
combinations, as this would simplify doing incompatible upgrades.


Carsten

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Sat, 10 Nov 2007 01:39:18 +0100
Carsten Lohrke <carlo@gentoo.org> wrote:
> Handling depends a bit upon, if EAPI should always be downwards
> compatible.

It won't be. It's likely that future EAPIs will introduce new
strictness requirements and remove certain legacy variables and
utilities.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Fabian Groffen]

On 09-11-2007 23:55:51 +0200, Petteri Räty wrote:
> Usually it's best that ebuild variables follow the order that is in
> skel.ebuild. So know we should decide where to place EAPI. I suggest we
> put it it after LICENSE as that's where the more technical stuff like
> SLOT starts. Attached a patch for skel.ebuild.

Just my 2 cents, I have placed EAPI right after the # $Header: line of
each ebuild, as I felt that it was the first thing to know of the
ebuild, as it describes how you possibly have to process the rest of the
ebuild.  Examples can be found in the prefix overlay, e.g.
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/app-shells/bash/bash-3.2_p17-r00.1.ebuild

It has the advantage for me that EAPI is never hidden away somewhere
down the ebuild, and it is just inserted by a simple bash script
automagically (eapify in this case).


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

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

Fabian Groffen kirjoitti:
> On 09-11-2007 23:55:51 +0200, Petteri Räty wrote:
>> Usually it's best that ebuild variables follow the order that is in
>> skel.ebuild. So know we should decide where to place EAPI. I suggest we
>> put it it after LICENSE as that's where the more technical stuff like
>> SLOT starts. Attached a patch for skel.ebuild.
> 
> Just my 2 cents, I have placed EAPI right after the # $Header: line of
> each ebuild, as I felt that it was the first thing to know of the
> ebuild, as it describes how you possibly have to process the rest of the
> ebuild.  Examples can be found in the prefix overlay, e.g.
> http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/app-shells/bash/bash-3.2_p17-r00.1.ebuild
> 
> It has the advantage for me that EAPI is never hidden away somewhere
> down the ebuild, and it is just inserted by a simple bash script
> automagically (eapify in this case).
> 

If we go with this solution then I guess eclasses must check for the
EAPI variable and then act accordingly. For example if the ebuild sets
EAPI=2 and the eclass is designed for EAPI=1 then it could be made to
die in case EAPI 2 is not backwards compatible. The main reason for me
asking this it that I plan to make the java eclasses use the EAPI 1
features.

Regards,
Petteri


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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Sun, 11 Nov 2007 21:01:41 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> If we go with this solution then I guess eclasses must check for the
> EAPI variable and then act accordingly. For example if the ebuild sets
> EAPI=2 and the eclass is designed for EAPI=1 then it could be made to
> die in case EAPI 2 is not backwards compatible. The main reason for me
> asking this it that I plan to make the java eclasses use the EAPI 1
> features.

Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to 'die'
at global scope. There's simply no way for eclasses to complain that
they're being misused.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Sun, 11 Nov 2007 21:01:41 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>> If we go with this solution then I guess eclasses must check for the
>> EAPI variable and then act accordingly. For example if the ebuild sets
>> EAPI=2 and the eclass is designed for EAPI=1 then it could be made to
>> die in case EAPI 2 is not backwards compatible. The main reason for me
>> asking this it that I plan to make the java eclasses use the EAPI 1
>> features.
> 
> Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to 'die'
> at global scope. There's simply no way for eclasses to complain that
> they're being misused.
> 

Well nothing formal but the ebuild developer should pick up ewarn/echo
/whatever messages coming from global scope. That's what we have in
debug.eclass atm.

Regards,
Petteri


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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Sun, 11 Nov 2007 21:21:30 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
> > 'die' at global scope. There's simply no way for eclasses to
> > complain that they're being misused.
> 
> Well nothing formal but the ebuild developer should pick up ewarn/echo
> /whatever messages coming from global scope. That's what we have in
> debug.eclass atm.

Past experience has shown that those messages will end up being seen by
end users and not being picked up by developers. People changing
eclasses generally don't force a metadata generation for every package
that uses the eclass.

I suspect that for existing eclasses, the safest way to proceed is to
make a new eclass and move common code into a third eclass. So you'd
have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting
foo-common.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Fabian Groffen]

On 11-11-2007 19:27:50 +0000, Ciaran McCreesh wrote:
> On Sun, 11 Nov 2007 21:21:30 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> > > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
> > > 'die' at global scope. There's simply no way for eclasses to
> > > complain that they're being misused.
> > 
> > Well nothing formal but the ebuild developer should pick up ewarn/echo
> > /whatever messages coming from global scope. That's what we have in
> > debug.eclass atm.
> 
> Past experience has shown that those messages will end up being seen by
> end users and not being picked up by developers. People changing
> eclasses generally don't force a metadata generation for every package
> that uses the eclass.
> 
> I suspect that for existing eclasses, the safest way to proceed is to
> make a new eclass and move common code into a third eclass. So you'd
> have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
> and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting
> foo-common.

This is indeed a very valid point that at least I have ignored for now.

In order (for me) not to mix up all kinds of issues here, this is my
percieved state with regard to EAPI.

EAPI=0 is the assumed to be used EAPI when no EAPI is specified in an
ebuild.  EAPI=1 as supported by Portage is like an extension of EAPI=0
where EAPI=0 is like a subset of EAPI=1.  For this reason current (soon
to be stable?) Portage, and at least the trunk version have EAPI=1
support, but can deal with EAPI=0 ebuilds fine.

In this setting, one could say that eclasses should remain EAPI=0, such
that all ebuilds will be able to work with them.

However, if an EAPI will require some change that makes it backwards
incompatible then this won't work any more.  What you get is that e.g.
for an eclass to work properly it needs to know about variable X, which
of course on previous EAPIs does not exist, and hence can result in
undesired behaviour.

While Ciaran's suggestion would allow some things to work there, it
still does not deal with the issue that eclasses should actually be
marked with an EAPI level too.  (Ideally they also would be part of the
digests of an ebuild, but that aside.)  A slight alternative to Ciaran's
idea here would be to make EAPI1, EAPI2 etc. subdirs in the eclass
directory where sort of eclass overloading can be done.  This would only
solve eclasses not to have an EAPI= in it, so they don't overwrite the
ebuild's value.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Sun, 11 Nov 2007 21:50:05 +0100
Fabian Groffen <grobian@gentoo.org> wrote:
> In this setting, one could say that eclasses should remain EAPI=0,
> such that all ebuilds will be able to work with them.

Mm. Slight problem with wording here, which is causing confusion.

Eclasses don't have an EAPI. Nor, strictly speaking, do ebuilds. An
EAPI is something that belongs to a cat/package-version::repo as a
whole, in the same way that DESCRIPTION etc does. Eclasses and ebuilds
on their own can merely support one or more different EAPIs.

> However, if an EAPI will require some change that makes it backwards
> incompatible then this won't work any more.  What you get is that e.g.
> for an eclass to work properly it needs to know about variable X,
> which of course on previous EAPIs does not exist, and hence can
> result in undesired behaviour.

Doesn't work going the other way too. Forcing eclasses to stick with
EAPI 1 means no slot deps, and the biggest use case for slot deps is
the KDE / Qt eclass mess.

> While Ciaran's suggestion would allow some things to work there, it
> still does not deal with the issue that eclasses should actually be
> marked with an EAPI level too.

Doesn't make sense. You can't have different EAPIs for different parts
of the same cat/pkg-version::repo. It wouldn't make sense for metadata
because you'd be merging different EAPIs into a single variable, and it
wouldn't make sense for functions because you can call between ebuilds
and eclasses and back again.

>  (Ideally they also would be part of the digests of an ebuild, but
> that aside.)

Would force a resign and redigest of every ebuild using an eclass every
time that eclass changed. Not doable.

> A slight alternative to Ciaran's idea here would be to make EAPI1,
> EAPI2 etc. subdirs in the eclass directory where sort of eclass
> overloading can be done.  This would only solve eclasses not to have
> an EAPI= in it, so they don't overwrite the ebuild's value.

That would require an EAPI bump. And if we're making inherit look in
lots of places, there're several other proposals in that area that
should be considered at the same time.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Carsten Lohrke]

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

On Sonntag, 11. November 2007, Ciaran McCreesh wrote:
> I suspect that for existing eclasses, the safest way to proceed is to
> make a new eclass and move common code into a third eclass. So you'd
> have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
> and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting
> foo-common.

And this is where it gets ugly - maybe finally a good reason for versioned 
eclasses (though I fear the misuse).

That it is not possible today to let an ebuild die in global scope is not a 
big issue, as you can in pkg_setup(), just as with missing use dependencies, 
just that the developer in question /should/ stumble about it, so in the best 
of all worlds the user base wouldn't ever notice. The only problem is the 
weakest link: One of us missing to care to invoke <eclass>_pkg_setup(), when 
necessary. 

Maybe it would in general not be bad to require eclass phase functions to be 
called, when the inheriting ebuild/eclass writes a custom phase function and 
having Portage to complain about it, unless some override_<eclass-phase> 
variable is set.


Carsten

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Chris Gianelloni]

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

On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote:
> I plan to make the java eclasses use the EAPI 1

Any chance we can *at least* wait until we have a release out the door
that has a portage version which supports these features *before* we
start trying to use them in the tree?  Our general rule was to not use
features for 1+ years since it was added to a *stable* portage before we
started using them.  Now, this isn't so much of an issue with individual
ebuilds, but you're talking about changing how the Java eclasses work,
essentially blocking *anyone* using an older portage (including everyone
installing from 2007.0 media) from using any package which inherits the
eclass.

Also, we should really think about this sort of thing before we start
using it.  How are we going to support EAPI changes in eclasses?  What
if I have an eclass with EAPI=1 features and I want to add some EAPI=2
features?  I think allowing EAPI=* globally in an eclass should be
prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds,
only.  In other words, you'd need new EAPI=1 eclasses for your EAPI=1
ebuilds.  Either that, or some way to say something like: "execute code
path A for EAPI=0 and execute code path B for EAPI=1" or something
similar.  I would suspect that the "best" current solution is to check
EAPI in the individual functions and perform the right actions based on
those functions, rather than marking an entire eclass.  After all, only
EAPI=* functions need to be "hidden" behind EAPI.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Tue, 13 Nov 2007 12:22:03 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> Any chance we can *at least* wait until we have a release out the door
> that has a portage version which supports these features *before* we
> start trying to use them in the tree?  Our general rule was to not use
> features for 1+ years since it was added to a *stable* portage before
> we started using them.

That was only the case because previously, using new features that
Portage didn't support would cause horrible breakage. Now, instead, the
ebuilds show up as being masked.

> Now, this isn't so much of an issue with individual ebuilds, but
> you're talking about changing how the Java eclasses work, essentially
> blocking *anyone* using an older portage (including everyone
> installing from 2007.0 media) from using any package which inherits
> the eclass.

They just need to upgrade their package manager first. Easy.

> Also, we should really think about this sort of thing before we start
> using it.  How are we going to support EAPI changes in eclasses?  What
> if I have an eclass with EAPI=1 features and I want to add some EAPI=2
> features?  I think allowing EAPI=* globally in an eclass should be
> prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds,
> only.

Doing an entire eclass for one specific EAPI generally isn't a good idea
since it's fairly likely that EAPI bumps will be a fairly common thing.

> In other words, you'd need new EAPI=1 eclasses for your EAPI=1
> ebuilds.  Either that, or some way to say something like: "execute
> code path A for EAPI=0 and execute code path B for EAPI=1" or
> something similar.  I would suspect that the "best" current solution
> is to check EAPI in the individual functions and perform the right
> actions based on those functions, rather than marking an entire
> eclass.  After all, only EAPI=* functions need to be "hidden" behind
> EAPI.

A solution with EAPI-agnostic code in foo-common.eclass and
EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more
readable and maintainable in most cases.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Chris Gianelloni]

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

On Tue, 2007-11-13 at 20:31 +0000, Ciaran McCreesh wrote:
> That was only the case because previously, using new features that
> Portage didn't support would cause horrible breakage. Now, instead, the
> ebuilds show up as being masked.

...which is just as good as "broken" when it happens to a new user first
installing Gentoo and wondering why he can't even follow the directions
in the Handbook.

What brought me to bring this up was the mention of changing of eclasses
which support a large number of ebuilds, effectively masking a
significant portion of the tree from our users.  Let's say that I added
EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 feature
in one of the functions.  Guess what?  I've now managed to mask
*portage* for users of older portage versions.  In fact, I've managed to
mask paludis and pkgcore, too.  Yes, this is an extreme example.  Yes,
it is completely possible.  Yes, that user would be completely screwed.

> > Now, this isn't so much of an issue with individual ebuilds, but
> > you're talking about changing how the Java eclasses work, essentially
> > blocking *anyone* using an older portage (including everyone
> > installing from 2007.0 media) from using any package which inherits
> > the eclass.
> 
> They just need to upgrade their package manager first. Easy.

Expecting users to do pretty much anything on their own is broken
behavior and should not be relied on for package manager compatibility.

> > Also, we should really think about this sort of thing before we start
> > using it.  How are we going to support EAPI changes in eclasses?  What
> > if I have an eclass with EAPI=1 features and I want to add some EAPI=2
> > features?  I think allowing EAPI=* globally in an eclass should be
> > prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds,
> > only.
> 
> Doing an entire eclass for one specific EAPI generally isn't a good idea
> since it's fairly likely that EAPI bumps will be a fairly common thing.
> 
> > In other words, you'd need new EAPI=1 eclasses for your EAPI=1
> > ebuilds.  Either that, or some way to say something like: "execute
> > code path A for EAPI=0 and execute code path B for EAPI=1" or
> > something similar.  I would suspect that the "best" current solution
> > is to check EAPI in the individual functions and perform the right
> > actions based on those functions, rather than marking an entire
> > eclass.  After all, only EAPI=* functions need to be "hidden" behind
> > EAPI.
> 
> A solution with EAPI-agnostic code in foo-common.eclass and
> EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more
> readable and maintainable in most cases.

Umm... So in the paragraph above, you say an EAPI-specific eclass isn't
a good idea, and here you push it as the proposed solution.  Huh?
Consistency, please...

I guess my real point is that we need to be *really* careful when using
this stuff.  It is *not* as simple as you make it out to sound.  All it
takes is one person adding an EAPI into an eclass somewhere to
completely screw over a *huge* number of our users.  I am just trying to
point this out and hopefully get discussion going on how to utilize
these great new features without potentially causing damage to our
user's machines and our reputation.

I still think that EAPI should not be allowed to be set in an eclass
globally.  All I can see is it causing problems for tons of users who
don't have a clue what is happening to their systems.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Tue, 13 Nov 2007 16:17:59 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Tue, 2007-11-13 at 20:31 +0000, Ciaran McCreesh wrote:
> > That was only the case because previously, using new features that
> > Portage didn't support would cause horrible breakage. Now, instead,
> > the ebuilds show up as being masked.
> 
> ...which is just as good as "broken" when it happens to a new user
> first installing Gentoo and wondering why he can't even follow the
> directions in the Handbook.

...so you just ensure that the handbook tells the user to upgrade the
package manager as quickly as possible.

> What brought me to bring this up was the mention of changing of
> eclasses which support a large number of ebuilds, effectively masking
> a significant portion of the tree from our users.  Let's say that I
> added EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1
> feature in one of the functions.  Guess what?  I've now managed to
> mask *portage* for users of older portage versions.  In fact, I've
> managed to mask paludis and pkgcore, too.  Yes, this is an extreme
> example.  Yes, it is completely possible.  Yes, that user would be
> completely screwed.

Uh huh, so if someone does something immensely stupid things go wrong.
How is this anything new?

> > > Now, this isn't so much of an issue with individual ebuilds, but
> > > you're talking about changing how the Java eclasses work,
> > > essentially blocking *anyone* using an older portage (including
> > > everyone installing from 2007.0 media) from using any package
> > > which inherits the eclass.
> > 
> > They just need to upgrade their package manager first. Easy.
> 
> Expecting users to do pretty much anything on their own is broken
> behavior and should not be relied on for package manager
> compatibility.

Eh? We already expect users to do lots on their own. Are you suggesting
that we should take over maintaining everyone's system for them?

> > A solution with EAPI-agnostic code in foo-common.eclass and
> > EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably
> > more readable and maintainable in most cases.
> 
> Umm... So in the paragraph above, you say an EAPI-specific eclass
> isn't a good idea, and here you push it as the proposed solution.
> Huh? Consistency, please...

Read it (and my explanation of it earlier in the thread) until you
understand it. There is nothing consistent in what I'm saying.

EAPI specific eclasses are a bad idea. Providing EAPI-agnostic eclasses
by way of multiple EAPI-specific shell eclasses is a good idea.

> I guess my real point is that we need to be *really* careful when
> using this stuff.  It is *not* as simple as you make it out to
> sound.

No no, it is as simple as I make it sound (which isn't simple simple,
but it isn't any more complicated than things people have to do
already).

If people stick to a) the way I described of handling non-trivial
eclasses that need to care about EAPIs, b) not using new EAPIs on
things that are hard deps of the package manager that aren't already in
the stageball and c) not nuking the last EAPI 0 versions of a package,
there isn't a problem.

In particular, there is absolutely no need to wait for updated stages
before using EAPI 1 for non-system packages. There isn't even a need to
avoid using EAPI 1 of things that are deps of a package manager, so
long as there remain EAPI 0 versions that are sufficient to satisfy the
dependencies.

For example, you could quite happily mark, say, doxygen 1.5 as EAPI 1,
without breaking the upgrade or install path for Paludis. Paludis 0.24
or older Portage would simply select doxygen 1.4 rather than 1.5, and
then once you'd upgraded to Paludis 0.26 the doxygen 1.5 update would
become available. The problem only occurs if either EAPI 0 versions are
nuked or if particular versions are required.

> All it takes is one person adding an EAPI into an eclass
> somewhere to completely screw over a *huge* number of our users.

All it takes is one person making any silly change to an eclass to
screw over a huge number of users.

> I still think that EAPI should not be allowed to be set in an eclass
> globally.  All I can see is it causing problems for tons of users who
> don't have a clue what is happening to their systems.

EAPI *can't* be set in an eclass correctly anyway because EAPI is
allowed to (and likely will in the future) change the behaviour of
inherit.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Wed, 14 Nov 2007 00:39:50 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
> Read it (and my explanation of it earlier in the thread) until you
> understand it. There is nothing consistent in what I'm saying.

...bleh. *in*consistent.

NNnnnneeeeeeeeeeedddd ccccoooooffffffffeeeeeeeeeeeee...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Chris Gianelloni]

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

On Wed, 2007-11-14 at 00:39 +0000, Ciaran McCreesh wrote:
> > Umm... So in the paragraph above, you say an EAPI-specific eclass
> > isn't a good idea, and here you push it as the proposed solution.
> > Huh? Consistency, please...
> 
> Read it (and my explanation of it earlier in the thread) until you
> understand it. There is nothing consistent in what I'm saying.

You are *so* correct.  There really is nothing consistent in your
replies.  Rather, you've decided to pick and choose how you respond to
maximize insult.  It's *so* much easier to simply avoid any potential
issues than to actually discuss them.  As such, I've decided to quit
responding to this thread until someone who wishes to actually
participate in a discussion, rather than trying to "win" it comes along.

Thank you for your input and have a nice day.

> > I still think that EAPI should not be allowed to be set in an eclass
> > globally.  All I can see is it causing problems for tons of users who
> > don't have a clue what is happening to their systems.
> 
> EAPI *can't* be set in an eclass correctly anyway because EAPI is
> allowed to (and likely will in the future) change the behaviour of
> inherit.

...and this proves my point.  Rather than simply stating this, you
decided to post $diety knows how many lines of completely worthless
information again and again.  Had you simply said *exactly this* at the
beginning, the thread/discussion would have been over.  This is exactly
what people mean when they say that they feel that you are not
participating in discussions fairly.  It's like you specifically hold
back information that you know and bait people into saying things simply
so you call put out the ace from your sleeve and point out how someone
else is wrong.

Yay!  You "win".

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Ciaran McCreesh]

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

On Tue, 13 Nov 2007 17:25:44 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > EAPI *can't* be set in an eclass correctly anyway because EAPI is
> > allowed to (and likely will in the future) change the behaviour of
> > inherit.
> 
> ...and this proves my point.  Rather than simply stating this, you
> decided to post $diety knows how many lines of completely worthless
> information again and again.  Had you simply said *exactly this* at
> the beginning, the thread/discussion would have been over.

Er, I did. Read my first post to the thread. That is exactly what I
said.

Then, once you've done that, read other people's questions, which expand
upon the original topic and which can't be handled simply by shoving
EAPI in each ebuild and doing nothing else.

> This is exactly what people mean when they say that they feel that
> you are not participating in discussions fairly.

What. Please explain how my original post to this thread wasn't
sufficient to answer the original question, and how other related but
more complex questions that other people posted later on are answered
merely by that.

I think you should go back, read the whole thread ordered by date and
then consider whether an apology for your behaviour is in order.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Josh Saddler]

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

Ciaran McCreesh wrote:
>> ...which is just as good as "broken" when it happens to a new user
>> first installing Gentoo and wondering why he can't even follow the
>> directions in the Handbook.
> 
> ...so you just ensure that the handbook tells the user to upgrade the
> package manager as quickly as possible.

That's already in the handbook. See
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=6#doc_chap2;
 substitute with the arch of your choice. It's the same file anyway.

Nothing wrong with the handbook, and don't nobody break it, neither.
Move along, nothing to see here. Scoot scoot.


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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

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

Chris Gianelloni kirjoitti:
> On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote:
>> I plan to make the java eclasses use the EAPI 1
> 
> Any chance we can *at least* wait until we have a release out the door
> that has a portage version which supports these features *before* we
> start trying to use them in the tree?  Our general rule was to not use
> features for 1+ years since it was added to a *stable* portage before we
> started using them.  Now, this isn't so much of an issue with individual
> ebuilds, but you're talking about changing how the Java eclasses work,
> essentially blocking *anyone* using an older portage (including everyone
> installing from 2007.0 media) from using any package which inherits the
> eclass.

I took this into consideration from the start. You misunderstood my
plans. I don't plan to just stick it globally for all current Java
ebuilds as there is nothing in EAPI=1 that would warrant that. You can
see my plans in more detail in a later post in this thread.

> 
> Also, we should really think about this sort of thing before we start
> using it.  How are we going to support EAPI changes in eclasses? 

As said in this thread you really can't set EAPI in an eclass.

Regards,
Petteri


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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 1143 bytes --]

Petteri Räty kirjoitti:
> Usually it's best that ebuild variables follow the order that is in
> skel.ebuild. So know we should decide where to place EAPI. I suggest we
> put it it after LICENSE as that's where the more technical stuff like
> SLOT starts. Attached a patch for skel.ebuild.
> 
> Regards,
> Petteri
> 

The predominant options seems to be before inherit so let's go with that
then. Will post more details on eclass stuff once I get further with
java stuff.

00:31 < Betelgeuse> zmedico: ping
01:02 < zmedico> Betelgeuse: pong
01:03 < Betelgeuse> zmedico: Haven't seen your thoughts on EAPI place in
ebuild
01:05 < zmedico> I'd say the ebuild should define it before the inherit
01:05 < zmedico> that's the simplest and safest thing to do
01:05 < Betelgeuse> zmedico: ok so I would test for EAPI=1 then in java
eclasses?
01:05 < Betelgeuse> zmedico: And maybe write eapi.eclass for testing
EAPI version
01:06 < Betelgeuse> zmedico: eapi 1 && <do stuff> etc
01:06 < Betelgeuse> If I only need one function then perhaps add it to
eutils
01:06 < zmedico> sure
01:06 < zmedico> yeah

Regards,
Petteri

[-- Attachment #1.2: eapi-location.patch --]
[-- Type: text/plain, Size: 858 bytes --]

Index: skel.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/skel.ebuild,v
retrieving revision 1.42
diff -u -r1.42 skel.ebuild
--- skel.ebuild	1 Jan 2007 12:18:17 -0000	1.42
+++ skel.ebuild	12 Nov 2007 23:09:35 -0000
@@ -11,6 +11,11 @@
 # will be committed to cvs, the details on that line will be automatically
 # generated to contain the correct data.
 
+# The EAPI variable tells the ebuild format in use.
+# Defaults to 0 if not specified. See current PMS draft for more details.
+# Eclasses will test for this variable if they need to use EAPI > 0 features.
+EAPI=1
+
 # inherit lists eclasses to inherit functions from. Almost all ebuilds should
 # inherit eutils, as a large amount of important functionality has been
 # moved there. For example, the $(get_libdir) mentioned below wont work

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

Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 632 bytes --]

Petteri Räty kirjoitti:
> Petteri Räty kirjoitti:
>> Usually it's best that ebuild variables follow the order that is in
>> skel.ebuild. So know we should decide where to place EAPI. I suggest we
>> put it it after LICENSE as that's where the more technical stuff like
>> SLOT starts. Attached a patch for skel.ebuild.
>>
>> Regards,
>> Petteri
>>
> 
> The predominant options seems to be before inherit so let's go with that
> then. Will post more details on eclass stuff once I get further with
> java stuff.
> 

Plah the patch was not the latest version that I committed. Let's try again.

Regards,
Petteri

[-- Attachment #1.2: eapi-location.patch --]
[-- Type: text/plain, Size: 954 bytes --]

Index: skel.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/skel.ebuild,v
retrieving revision 1.42
diff -u -r1.42 skel.ebuild
--- skel.ebuild	1 Jan 2007 12:18:17 -0000	1.42
+++ skel.ebuild	12 Nov 2007 23:12:10 -0000
@@ -11,6 +11,13 @@
 # will be committed to cvs, the details on that line will be automatically
 # generated to contain the correct data.
 
+# The EAPI variable tells the ebuild format in use.
+# Defaults to 0 if not specified. See current PMS draft for more details.
+# Eclasses will test for this variable if they need to use EAPI > 0 features.
+# Ebuilds should not define EAPI=1 unless they need to use features added
+# in that version.
+#EAPI=1
+
 # inherit lists eclasses to inherit functions from. Almost all ebuilds should
 # inherit eutils, as a large amount of important functionality has been
 # moved there. For example, the $(get_libdir) mentioned below wont work

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