[gentoo-dev] EAPI usage in main tree

[gentoo-dev] EAPI usage in main tree

[Tomáš Chvátal]

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

Hi,
I would like to upgrade tree-wide policy for EAPI usage in main tree.
Currently we say that developers can use any named version they wish or
find sufficient.
I would on other hand like to have all ebuilds to use Latest EAPI
version possible (given the eclasses support it [hint hint maintainers
of eclasses should always try to support latest :P]) with expection for
base-system or more specialy depgraph for portage that needs to be
EAPI0. [[ And here we need to find out some upgrade proccess that would
work for everyone so we could somehow migrate them too :)]]

With this usually new developers should be aware only of latest EAPI and
wont need to memorize what which EAPI support. Heck even I sometimes
forget what i can do with some version and whatnot.

Winner for being PITA in this race is python.eclass that HAS completely
different behavior based on EAPI version used...

Cheers

Tomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+sf4ACgkQHB6c3gNBRYeR6wCeNKsc8LnLw3ltkc1KKllzMP3u
bXMAnRlbWZjGpQ7Zc2abdxtoJFKRVszS
=lkXl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI usage in main tree

["Paweł Hajdan, Jr."]

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

On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
> I would like to upgrade tree-wide policy for EAPI usage in main tree.

I have a great idea for you.

How about creating a project (possibly a subproject of QA or something
else) that would help people do that? In case of no response from
maintainers just do your job, and that should get the tree converted
more quickly than setting a policy.

My main point is that said "X should be Y" does not automatically make
it so. We'd have to think about the migration plan anyway.

Paweł


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

Re: [gentoo-dev] EAPI usage in main tree

[Markos Chandras]

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

On Tue, Jan 25, 2011 at 01:13:06PM +0100, "Paweł Hajdan, Jr." wrote:
> On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
> > I would like to upgrade tree-wide policy for EAPI usage in main tree.
> 
> I have a great idea for you.
> 
> How about creating a project (possibly a subproject of QA or something
> else) that would help people do that? In case of no response from
> maintainers just do your job, and that should get the tree converted
> more quickly than setting a policy.
Please don't! QA is way too understaffed. We ain't gonna convert any
ebuilds. This has nothing to do with QA. Let maintainers handle this
> 
> My main point is that said "X should be Y" does not automatically make
> it so. We'd have to think about the migration plan anyway.
> 
> Paweł
> 
@Tomas, I don't follow. You mean migrate existing ebuilds or use the
latest EAPI from now on?

Regards,
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Key ID: B4AFF2C2
Key FP: 660A 0742 84EC 26F1 9EDB  F00A FA83 5A15 B4AF F2C2

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

Re: [gentoo-dev] EAPI usage in main tree

[Tomáš Chvátal]

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

Dne 25.1.2011 13:25, Markos Chandras napsal(a):
> On Tue, Jan 25, 2011 at 01:13:06PM +0100, "Paweł Hajdan, Jr." wrote:
>> How about creating a project (possibly a subproject of QA or something
>> else) that would help people do that? In case of no response from
>> maintainers just do your job, and that should get the tree converted
>> more quickly than setting a policy.
> Please don't! QA is way too understaffed. We ain't gonna convert any
> ebuilds. This has nothing to do with QA. Let maintainers handle this
Pavel does not ask for us to migrate the ebuilds, but the eclasses, wich
we do anyway now :)
>>
>> My main point is that said "X should be Y" does not automatically make
>> it so. We'd have to think about the migration plan anyway.
>>
>> Paweł
>>
> @Tomas, I don't follow. You mean migrate existing ebuilds or use the
> latest EAPI from now on?
> 
God no, when you do bump you use new eapi :) not retroactively revert
all ebuilds to latest.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+wtoACgkQHB6c3gNBRYe0lACeI/ir1DEcoxIpL/l0TEjDr5IZ
smQAn2ydpf013aaqR94t7A6MYb7nkslF
=j9iM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI usage in main tree

[Markos Chandras]

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

On Tue, Jan 25, 2011 at 01:32:27PM +0100, Tomáš Chvátal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dne 25.1.2011 13:25, Markos Chandras napsal(a):
> > On Tue, Jan 25, 2011 at 01:13:06PM +0100, "Paweł Hajdan, Jr." wrote:
> >> How about creating a project (possibly a subproject of QA or something
> >> else) that would help people do that? In case of no response from
> >> maintainers just do your job, and that should get the tree converted
> >> more quickly than setting a policy.
> > Please don't! QA is way too understaffed. We ain't gonna convert any
> > ebuilds. This has nothing to do with QA. Let maintainers handle this
> Pavel does not ask for us to migrate the ebuilds, but the eclasses, wich
> we do anyway now :)
Then I am sorry
> >>
> >> My main point is that said "X should be Y" does not automatically make
> >> it so. We'd have to think about the migration plan anyway.
> >>
> >> Paweł
> >>
> > @Tomas, I don't follow. You mean migrate existing ebuilds or use the
> > latest EAPI from now on?
> > 
> God no, when you do bump you use new eapi :) not retroactively revert
> all ebuilds to latest.
Ok that works for me. As Alex said, maybe a repoman warning would be a
good start

> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk0+wtoACgkQHB6c3gNBRYe0lACeI/ir1DEcoxIpL/l0TEjDr5IZ
> smQAn2ydpf013aaqR94t7A6MYb7nkslF
> =j9iM
> -----END PGP SIGNATURE-----
> 

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Key ID: B4AFF2C2
Key FP: 660A 0742 84EC 26F1 9EDB  F00A FA83 5A15 B4AF F2C2

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

Re: [gentoo-dev] EAPI usage in main tree

[Tomáš Chvátal]

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

Dne 25.1.2011 13:13, "Paweł Hajdan, Jr." napsal(a):
> On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
>> I would like to upgrade tree-wide policy for EAPI usage in main tree.
> 
> I have a great idea for you.
> 
> How about creating a project (possibly a subproject of QA or something
> else) that would help people do that? In case of no response from
> maintainers just do your job, and that should get the tree converted
> more quickly than setting a policy.
> 
> My main point is that said "X should be Y" does not automatically make
> it so. We'd have to think about the migration plan anyway.
> 
> Paweł
> 
Why would we need subproject for this.
QA team itself is done to help developers with this tasks. So if someone
come to #gentoo-qa and ask us to help him with his shiny eclass we won't
sent him somewhere else where sun is not shining :P

And that apply even if developer itself is not maintainer and did not
get reply from the maintainer... :)

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+wiIACgkQHB6c3gNBRYcXQwCgmnvpToj97h+P11ljcXjJiL3j
55UAn3FPehseXf8OkwoJvqbSp9dECdsK
=1zHu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI usage in main tree

["Paweł Hajdan, Jr."]

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

On 1/25/11 1:29 PM, Tomáš Chvátal wrote:
> Why would we need subproject for this.

The idea was that if you want to introduce a new policy, you should also
provide resources to make it possible. The below satisfies most of that.

> QA team itself is done to help developers with this tasks. So if someone
> come to #gentoo-qa and ask us to help him with his shiny eclass we won't
> sent him somewhere else where sun is not shining :P

SGTM. One additional point is that there may be rarely bumped packages
that won't be migrated "naturally", but will need an update just for the
EAPI bump, and the maintainers may just ignore this, so there should be
someone actively monitoring the progress.

> And that apply even if developer itself is not maintainer and did not
> get reply from the maintainer... :)

Yes, definitely.


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

[gentoo-dev] Re: EAPI usage in main tree

[Alex Alexander]

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

On Tue, Jan 25, 2011 at 12:20:30PM +0100, Tomáš Chvátal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> I would like to upgrade tree-wide policy for EAPI usage in main tree.
> Currently we say that developers can use any named version they wish or
> find sufficient.
> I would on other hand like to have all ebuilds to use Latest EAPI
> version possible (given the eclasses support it [hint hint maintainers
> of eclasses should always try to support latest :P]) with expection for
> base-system or more specialy depgraph for portage that needs to be
> EAPI0. [[ And here we need to find out some upgrade proccess that would
> work for everyone so we could somehow migrate them too :)]]
> 
> With this usually new developers should be aware only of latest EAPI and
> wont need to memorize what which EAPI support. Heck even I sometimes
> forget what i can do with some version and whatnot.
> 
> Winner for being PITA in this race is python.eclass that HAS completely
> different behavior based on EAPI version used...

I agree with the idea, however, just creating the policy won't be
enough.

We should make repoman print a warning if an older EAPI is used, maybe
even refuse to commit (without -f), at least on version bumps, to get
the devs' attention. base-system excluded for now, obviously. 

> Cheers
> 
> Tomas
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk0+sf4ACgkQHB6c3gNBRYeR6wCeNKsc8LnLw3ltkc1KKllzMP3u
> bXMAnRlbWZjGpQ7Zc2abdxtoJFKRVszS
> =lkXl
> -----END PGP SIGNATURE-----

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

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

Re: [gentoo-dev] Re: EAPI usage in main tree

[Fabian Groffen]

On 25-01-2011 14:25:05 +0200, Alex Alexander wrote:
> We should make repoman print a warning if an older EAPI is used, maybe
> even refuse to commit (without -f), at least on version bumps, to get
> the devs' attention. base-system excluded for now, obviously. 

How obvious is that if Python is already EAPI >0?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] EAPI usage in main tree

[Thomas Sachau]

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

Am 25.01.2011 12:20, schrieb Tomáš Chvátal:
> Hi,
> I would like to upgrade tree-wide policy for EAPI usage in main tree.
> Currently we say that developers can use any named version they wish or
> find sufficient.
> I would on other hand like to have all ebuilds to use Latest EAPI
> version possible (given the eclasses support it [hint hint maintainers
> of eclasses should always try to support latest :P]) with expection for
> base-system or more specialy depgraph for portage that needs to be
> EAPI0. [[ And here we need to find out some upgrade proccess that would
> work for everyone so we could somehow migrate them too :)]]
> 
> With this usually new developers should be aware only of latest EAPI and
> wont need to memorize what which EAPI support. Heck even I sometimes
> forget what i can do with some version and whatnot.

Do you have some more arguments for your request? Most new developers will have to know about all
EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not
use the newest EAPI.

As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you
maintain, you can always bump them to the latest EAPI. But why do you want to force this on all
developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI?

> 
> Winner for being PITA in this race is python.eclass that HAS completely
> different behavior based on EAPI version used...

The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to
read/understand. And just because the eclass has additional EAPI-specific behaviour, this is
specific to this eclass and should not be an argument for the general EAPI discussion.

> 
> Cheers
> 
> Tomas

-- 
Thomas Sachau

Gentoo Linux Developer


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

Re: [gentoo-dev] EAPI usage in main tree

[Tomáš Chvátal]

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

Dne 25.1.2011 14:33, Thomas Sachau napsal(a):
> Do you have some more arguments for your request? Most new developers will have to know about all
> EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not
> use the newest EAPI.
> 
> As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you
> maintain, you can always bump them to the latest EAPI. But why do you want to force this on all
> developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI?
> 
1) less stuff to memorize:
seriously mostly if you just use latest EAPI and 0 you can make yourself
not to bother for example with quirks required to use prefix properly in
EAPI2
2) easier migration and deprecation of old EAPIs:
If we enforce latest EAPI to be used EAPIs will be phased out by
automatic upgrade process where we can migrate them.
3) using less codepaths:
so we can find out what the heck is wrong easier in both eclasses and
portage if we know that it was hit with the latest code
4) eapis are done to bring shiny features:
usually ebuilds using new EAPI should be cleaner and easier to read than
the old EAPI ones, by worst case scenario you just add the EAPI=Version
line to the ebuild which makes it bit larger.

>>
>> Winner for being PITA in this race is python.eclass that HAS completely
>> different behavior based on EAPI version used...
> 
> The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to
> read/understand. And just because the eclass has additional EAPI-specific behaviour, this is
> specific to this eclass and should not be an argument for the general EAPI discussion.
> 

I just said that the eclass has different behaviour for each eapi. Which
is true, nothing more nothing less. And you have to memorize it and
check the behavior in reported bug with various EAPIs.

Tomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+2YIACgkQHB6c3gNBRYdW/gCbB/Ki35r13CfUJPiaDNhgoAEO
BfUAn3b/t9BEpU6Cd26btvCReTsizv66
=qFH3
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI usage in main tree

[Thomas Sachau]

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

Am 25.01.2011 15:09, schrieb Tomáš Chvátal:
> Dne 25.1.2011 14:33, Thomas Sachau napsal(a):
>> Do you have some more arguments for your request? Most new developers will have to know about all
>> EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not
>> use the newest EAPI.
> 
>> As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you
>> maintain, you can always bump them to the latest EAPI. But why do you want to force this on all
>> developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI?
> 
> 1) less stuff to memorize:
> seriously mostly if you just use latest EAPI and 0 you can make yourself
> not to bother for example with quirks required to use prefix properly in
> EAPI2

You are free to only use latest EAPI and EAPI-0 in your ebuilds. So you dont have to memorize the
changes in the other EAPI versions. But why do you want to force this on me too? I have to maintain
my ebuilds and have to debug the bugs for it, so why not give me the choice to use whatever i prefer
to use?

> 2) easier migration and deprecation of old EAPIs:
> If we enforce latest EAPI to be used EAPIs will be phased out by
> automatic upgrade process where we can migrate them.

Why would any migration be easier? You always have to check the difference between current and
planned EAPI during a migration, this wont change with the policy. And why do you want to deprecate
older EAPI versions?

> 3) using less codepaths:
> so we can find out what the heck is wrong easier in both eclasses and
> portage if we know that it was hit with the latest code

As i said for the previous points: If you maintain something, you can use whatever you like,
including the latest versions, so this is no issue i can see.

> 4) eapis are done to bring shiny features:
> usually ebuilds using new EAPI should be cleaner and easier to read than
> the old EAPI ones, by worst case scenario you just add the EAPI=Version
> line to the ebuild which makes it bit larger.

Sure, but if it is just another line and nothing else changes, why should i then even add that line?
I prefer to keep things to the minimum required and if it works fine for me without the additional
line, why should i add it?

> 
>>>
>>> Winner for being PITA in this race is python.eclass that HAS completely
>>> different behavior based on EAPI version used...
> 
>> The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to
>> read/understand. And just because the eclass has additional EAPI-specific behaviour, this is
>> specific to this eclass and should not be an argument for the general EAPI discussion.
> 
> 
> I just said that the eclass has different behaviour for each eapi. Which
> is true, nothing more nothing less. And you have to memorize it and
> check the behavior in reported bug with various EAPIs.

This means, that you either have to convince the python eclass maintainers to reduce the complexity
of their eclass or you dont maintain ebuilds, which have to use their eclasses.

Alternatively you can just remember the behaviour for the latest EAPI and use that in your ebuilds,
so how does the different behaviour for previous EAPI versions create issues for you?

> 
> Tomas

-- 
Thomas Sachau

Gentoo Linux Developer


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

Re: [gentoo-dev] EAPI usage in main tree

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 532 bytes --]

2011-01-25 15:34:58 Thomas Sachau napisał(a):
> This means, that you either have to convince the python eclass maintainers to reduce the complexity
> of their eclass

There are plans to remove some EAPI-specific behavior by removing support for old EAPIs.
E.g. when there are no remaining ebuilds using distutils.eclass, python_mod_optimize() or
python_mod_cleanup() in old EAPIs, then it will be possible to remove large parts of
python_mod_optimize() and python_mod_cleanup().

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] EAPI usage in main tree

[Peter Volkov]

В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет:
> Do you have some more arguments for your request? Most new developers
> will have to know about all EAPi versions anyway since they join an
> existing team with existing ebuilds, which will mostly not use the
> newest EAPI.
> 
> As an argument againt this: Noone forces you to keep older EAPI
> versions of the ebuilds you maintain, you can always bump them to the
> latest EAPI. But why do you want to force this on all developers? 

I think your first paragraph is actually the argument to use latest EAPI
whenever possible. Such policy provides us with the path to avoid
situation you described while insisting on keeping old EAPI's obviously
will force new developer to learn ancient knowledge. IOW, such policy
provides path to simplify work in team.

-- 
Peter.

Re: [gentoo-dev] EAPI usage in main tree

[Thomas Sachau]

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

Am 25.01.2011 17:40, schrieb Peter Volkov:
> В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет:
>> Do you have some more arguments for your request? Most new developers
>> will have to know about all EAPi versions anyway since they join an
>> existing team with existing ebuilds, which will mostly not use the
>> newest EAPI.
>>
>> As an argument againt this: Noone forces you to keep older EAPI
>> versions of the ebuilds you maintain, you can always bump them to the
>> latest EAPI. But why do you want to force this on all developers? 
> 
> I think your first paragraph is actually the argument to use latest EAPI
> whenever possible. Such policy provides us with the path to avoid
> situation you described while insisting on keeping old EAPI's obviously
> will force new developer to learn ancient knowledge. IOW, such policy
> provides path to simplify work in team.
> 

If you as a maintainer or the maintaining team want to migrate your ebuilds to the latest EAPI, this
is your decision. But if i am fine with an older EAPI version in those ebuilds i do maintain, what
is wrong with that? Why do you want to force others into migrating to a newer EAPI, if they dont
want it for whatever reason (like no need or upgrade path)?

The only "nice to have" situation is, when you take over an existing ebuild. If it already uses the
latest EAPI, you dont have to migrate it. On one side, you wont be able to avoid the migration,
since exactly those ebuilds, which need a new maintainer wont be touched, so also wont be using the
latest EAPI. On the other side, we have docs, which show you the changes with each EAPI, so you can
read it once, adjust the ebuild and forget it again. I see nothing gained in this situation either,
so we are back to my question above.

The (maybe inofficial) suggestion is already to use the latest EAPI in new ebuilds. This is ok for
me, as long as it is a suggestion. The same goes for the migration of ebuilds to the latest EAPI.
But i am against the idea to enforce this for either new or even existing ebuilds. I prefer to do
other work than useless EAPI-migration without a real need/benefit for me or the users.

-- 
Thomas Sachau

Gentoo Linux Developer


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

Re: [gentoo-dev] EAPI usage in main tree

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1024 bytes --]

On Tuesday 25 January 2011 20:13:40 Thomas Sachau wrote:
>
> The (maybe inofficial) suggestion is already to use the latest EAPI in new ebuilds. This is ok for
> me, as long as it is a suggestion. The same goes for the migration of ebuilds to the latest EAPI.
> But i am against the idea to enforce this for either new or even existing ebuilds. I prefer to do
> other work than useless EAPI-migration without a real need/benefit for me or the users.
> 

This is fine as long as you do pure standalone work. As soon as you use a single eclass, you basically require the eclass maintainers to provide support for each and every EAPI - and that's an important point here.  

AFAIK the kde team will soon require EAPI (>)= 3 for all ebuilds using kde4-* eclasses. Similar restrictions already exist in other cases _in order to ease maintainability_. Why not go all the way and clean the mess out?

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

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

Re: [gentoo-dev] EAPI usage in main tree

[Lars Wendler]

[-- Attachment #1: Type: Text/Plain, Size: 1724 bytes --]

Hi,

I don'f feel very well with this idea especially because no matter how hard I 
try I don't get comfortable with EAPI-3. No offense to our prefix guys, you 
surely did a hell of a good job and EAPI-3 seems to really get you out of 
quite some trouble you had with earlier EAPIs, but... 
I for myself never tried a prefix installation and I don't have any intentions 
to do this in the foreseeable future so I still prefer EAPI-2 wherever I can 
simply because EAPI-3 imposes overhead on my side which I have no real benefit 
from and I have no real clue about how to write proper EAPI-3 ebuilds.

-- 
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler

Am Dienstag 25 Januar 2011, 12:20:30 schrieb Tomáš Chvátal:
> Hi,
> I would like to upgrade tree-wide policy for EAPI usage in main tree.
> Currently we say that developers can use any named version they wish or
> find sufficient.
> I would on other hand like to have all ebuilds to use Latest EAPI
> version possible (given the eclasses support it [hint hint maintainers
> of eclasses should always try to support latest :P]) with expection for
> base-system or more specialy depgraph for portage that needs to be
> EAPI0. [[ And here we need to find out some upgrade proccess that would
> work for everyone so we could somehow migrate them too :)]]
> 
> With this usually new developers should be aware only of latest EAPI and
> wont need to memorize what which EAPI support. Heck even I sometimes
> forget what i can do with some version and whatnot.
> 
> Winner for being PITA in this race is python.eclass that HAS completely
> different behavior based on EAPI version used...
> 
> Cheers
> 
> Tomas


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

Re: [gentoo-dev] EAPI usage in main tree

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 786 bytes --]

2011-01-25 22:33:16 Lars Wendler napisał(a):
> Hi,
> 
> I don'f feel very well with this idea especially because no matter how hard I 
> try I don't get comfortable with EAPI-3. No offense to our prefix guys, you 
> surely did a hell of a good job and EAPI-3 seems to really get you out of 
> quite some trouble you had with earlier EAPIs, but... 
> I for myself never tried a prefix installation and I don't have any intentions 
> to do this in the foreseeable future so I still prefer EAPI-2 wherever I can 
> simply because EAPI-3 imposes overhead on my side which I have no real benefit 
> from and I have no real clue about how to write proper EAPI-3 ebuilds.

You can use EAPI="3" without supporting prefix installations.

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] EAPI usage in main tree

[justin]

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

On 25/01/11 22:33, Lars Wendler wrote:
> Hi,
> 
> I don'f feel very well with this idea especially because no matter how hard I 
> try I don't get comfortable with EAPI-3. No offense to our prefix guys, you 
> surely did a hell of a good job and EAPI-3 seems to really get you out of 
> quite some trouble you had with earlier EAPIs, but... 
> I for myself never tried a prefix installation and I don't have any intentions 
> to do this in the foreseeable future so I still prefer EAPI-2 wherever I can 
> simply because EAPI-3 imposes overhead on my side which I have no real benefit 
> from and I have no real clue about how to write proper EAPI-3 ebuilds.
> 

You can use EAPI=3 completely independent from prefix support.


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

Re: [gentoo-dev] EAPI usage in main tree

[Ulrich Mueller]

>>>>> On Tue, 25 Jan 2011, Lars Wendler wrote:

> I don'f feel very well with this idea especially because no matter
> how hard I try I don't get comfortable with EAPI-3. No offense to
> our prefix guys, you surely did a hell of a good job and EAPI-3
> seems to really get you out of quite some trouble you had with
> earlier EAPIs, but... I for myself never tried a prefix installation
> and I don't have any intentions to do this in the foreseeable future
> so I still prefer EAPI-2 wherever I can simply because EAPI-3
> imposes overhead on my side which I have no real benefit from and I
> have no real clue about how to write proper EAPI-3 ebuilds.

As long as your ebuild doesn't need any keywords for prefix
architectures, nothing forces you to use ED and EROOT variables
instead of D and ROOT.

In other words, you can simply change the EAPI declaration in an
ebuild from 2 to 3 and it will continue to work.

Ulrich