В Втр, 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.

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

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

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/

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

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

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.

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