[gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.

[gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.

[Ralph Sennhauser]

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

From time to time the topic of deprecating EAPIs comes up and usually
one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
Then someone comes along and asks what is the point? Indeed, a fair
question.

The following tries to take a different approach to the topic. It's not
all thought through in detail, but that wont happen anytime soon,
after all it's on my TODO for long enough. So I present it in the hope
others will try to poke holes into it or even pick it up.


EAPI=0 requirement pointless?
-----------------------------

The EAPI=0 requirement comes from having to provide an update path for
systems with a package manager without EAPI support. By now we are
talking about really ancient systems and it's questionable if there is
any merit in supporting such.

Further the situation is that some of the maintainers of must be EAPI 0
ebuilds already moved on as the majority of users will profit from a
bump. As a result the clean upgrade path is already borked and the
value of keeping others at EAPI=0 deteriorates further and further.

Forcing EAPI 0 on some maintainers for all eternity doesn't strike me
as brilliant, quite the opposite frankly. After all new EAPIs are
supposed to contain bug fixes and new features required to write better
ebuilds.


If all installed PMs supported EAPI?
------------------------------------

The issue of an update path is reduced to keeping intermediate 
versions in tree.

Those PMs also support EAPI=1, rendering EAPI=0 obsolete.


Base EAPI
---------

Systems without having a package manager installed that supports at
least the 'Base EAPI' aren't considered supported any longer. 

Maintainers of system packages can use the Base EAPI without worrying.

Maintainers of system packages can use more recent EAPIs but need to
take special care.


Value of Base EAPI
------------------

Maintainers of system packages need to be able to use newer EAPIs
after some time. They can wait but not forever. built_with_use removal
is one example, strong vs weak blockers an other.

The value can be based on time ( i.e. after 3 years ) or set by council
decision. A combination is fine as well.

The value should be kept low enough so the rule "maintainers don't have
to care about using it" holds.

The need of derived distributions / package managers should be
considered, ie. let them catch up if necessary.

Security updates should be possible for some time without full updates.
This extends to other packages as well. So maintainers of critical non
system packages can use this EAPI as well if they want.

Guess EAPI=2 would be a reasonable compromiss.


Deprecation?
------------

EAPIs below the base EAPI can be considered deprecated if one desires.

References in devmanual can be removed and so the document be
simplified. 

Once there are only few ebuild of a deprecated EAPI left, it might make
sense to convert them and add a repoman check so the number of used
EAPIs is kept reasonable.

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

Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.

[Walter Dnes]

On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
> From time to time the topic of deprecating EAPIs comes up and usually
> one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
> Then someone comes along and asks what is the point? Indeed, a fair
> question.

  It's my understanding that higher EAPI levels include more features.
How backwards compatable are the EAPI levels?  I.e. assume that we take
an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top,
without any other changes.  Are there any circumstances where the ebuild
would behave differently and/or break?

  The current default, if EAPI is not specified, is EAPI 0.  What I'm
getting at is... can we safely tell portage to assume that all ebuilds
with no EAPI declaration are EAPI 1 (or 2 or 3, etc)?  Or will that
break some ebuilds?  Actually, if only a small percentage of ebuilds
break, then it might not be too much of an effort to fix that small
subset.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.

[Ciaran McCreesh]

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

On Fri, 12 Oct 2012 16:38:06 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
> > From time to time the topic of deprecating EAPIs comes up and
> > usually one suggestion is to keep 0 and start with converting EAPI
> > 1 ebuilds. Then someone comes along and asks what is the point?
> > Indeed, a fair question.
> 
>   It's my understanding that higher EAPI levels include more features.
> How backwards compatable are the EAPI levels?  I.e. assume that we
> take an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at
> the top, without any other changes.  Are there any circumstances
> where the ebuild would behave differently and/or break?

In EAPIs after 1, as well as adding shiny new toys, we've removed
various deprecated things, split up phase functions, and made some
helpers error on invalid input.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/10/12 04:38 PM, Walter Dnes wrote:
> On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
>> From time to time the topic of deprecating EAPIs comes up and
>> usually one suggestion is to keep 0 and start with converting
>> EAPI 1 ebuilds. Then someone comes along and asks what is the
>> point? Indeed, a fair question.
> 
> It's my understanding that higher EAPI levels include more
> features. How backwards compatable are the EAPI levels?  I.e.
> assume that we take an ebuild with EAPI 0, and slap in EAPI=1 (or 2
> or 3, etc) at the top, without any other changes.  Are there any
> circumstances where the ebuild would behave differently and/or
> break?

Yes.  There is more than just new features that have been added.  Some
default operations have changed.  Eclass behaviour can also be different.

I'll let others go into the details, but one of the big changes
between EAPIs is the way an unspecified DEPEND or RDEPEND is handled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlB4gVYACgkQ2ugaI38ACPB45QD+PC6PvspnXdmOhMAEOIDPxh2m
4RDWrTw8t86O+iyKodsA/RdRo1r1Xxc734hXbAwtZlxjC3KcU/mnGQVysvflOdjW
=uk9m
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.

[Alexandre Rostovtsev]

On Fri, 2012-10-12 at 16:38 -0400, Walter Dnes wrote:
>   It's my understanding that higher EAPI levels include more features.
> How backwards compatable are the EAPI levels?  I.e. assume that we take
> an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top,
> without any other changes.  Are there any circumstances where the ebuild
> would behave differently and/or break?

See http://devmanual.gentoo.org/ebuild-writing/eapi/index.html

Updating an ebuild from EAPI0 to EAPI1 without changes should be safe.

Updating from EAPI0 to EAPI2 or higher without changes is not safe; at
the minimum, econf calls would need to be moved from src_compile to
src_configure.

[gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Ryan Hill]

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

On Fri, 12 Oct 2012 12:53:15 +0200
Ralph Sennhauser <sera@gentoo.org> wrote:

> The EAPI=0 requirement comes from having to provide an update path for
> systems with a package manager without EAPI support. By now we are
> talking about really ancient systems and it's questionable if there is
> any merit in supporting such.
> 
> Further the situation is that some of the maintainers of must be EAPI 0
> ebuilds already moved on as the majority of users will profit from a
> bump. As a result the clean upgrade path is already borked and the
> value of keeping others at EAPI=0 deteriorates further and further.

Yeah as soon as python went it was pretty much pointless.  I don't see any
value in forcing system packages to EAPI 0 anymore.  Everything you're saying
makes sense to me at least.

I'd argue against deprecating EAPI 0 any time soon though.  Killing EAPI 1
would be a better idea.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Ralph Sennhauser]

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

On Fri, 12 Oct 2012 21:10:23 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> I'd argue against deprecating EAPI 0 any time soon though.  Killing
> EAPI 1 would be a better idea.

I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
gone from tree in 3-5 years once the EAPI=0 requirement is lifted.

Currently we have only 6 official EAPIs which is still manageable to
remember the details of each. Though it might be confusing for new
developers. Once we are at 20 EAPIs it will be an issue also for
seasoned folks.

Therefore deprecation is a given, how to go about it is certainly up to
discussion. What do you see as an acceptable path here?

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

[gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Ryan Hill]

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

On Sat, 13 Oct 2012 08:28:20 +0200
Ralph Sennhauser <sera@gentoo.org> wrote:

> On Fri, 12 Oct 2012 21:10:23 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> 
> > I'd argue against deprecating EAPI 0 any time soon though.  Killing
> > EAPI 1 would be a better idea.
> 
> I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
> gone from tree in 3-5 years once the EAPI=0 requirement is lifted.

How many packages in the tree don't define EAPI at all?  It's been a while
since I looked, but I remember it was a pretty big number.  Maybe things have
changed.

> Currently we have only 6 official EAPIs which is still manageable to
> remember the details of each. Though it might be confusing for new
> developers. Once we are at 20 EAPIs it will be an issue also for
> seasoned folks.

Agreed.  We will definitely have to do some pruning at some point.

> Therefore deprecation is a given, how to go about it is certainly up to
> discussion. What do you see as an acceptable path here?

I think an EAPI becomes a candidate for removal when the number of packages
using it becomes small enough that a sufficiently motivated/bored/gullible
person could take on the task of porting them all to a newer EAPI. EAPI 0 is
our baseline (all EAPIs are defined as "EAPI 0 plus/minus foo") and thus
should never* be removed.  Anything else is fair game.


*for varying lengths of never.  If it becomes completely irrelevant then
yeah just boot it.

-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El mar, 16-10-2012 a las 23:42 -0600, Ryan Hill escribió:
> On Sat, 13 Oct 2012 08:28:20 +0200
> Ralph Sennhauser <sera@gentoo.org> wrote:
> 
> > On Fri, 12 Oct 2012 21:10:23 -0600
> > Ryan Hill <dirtyepic@gentoo.org> wrote:
> > 
> > > I'd argue against deprecating EAPI 0 any time soon though.  Killing
> > > EAPI 1 would be a better idea.
> > 
> > I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
> > gone from tree in 3-5 years once the EAPI=0 requirement is lifted.
> 
> How many packages in the tree don't define EAPI at all?  It's been a while
> since I looked, but I remember it was a pretty big number.  Maybe things have
> changed.
> 
> > Currently we have only 6 official EAPIs which is still manageable to
> > remember the details of each. Though it might be confusing for new
> > developers. Once we are at 20 EAPIs it will be an issue also for
> > seasoned folks.
> 
> Agreed.  We will definitely have to do some pruning at some point.

Would be easier to prune old versions if we "force" them to be less
using at least preventing new ebuilds to use them. For example, what is
the advantage for a new ebuild to still rely on old src_compile phase
instead of src_prepare/configure...?

> 
> > Therefore deprecation is a given, how to go about it is certainly up to
> > discussion. What do you see as an acceptable path here?
> 
> I think an EAPI becomes a candidate for removal when the number of packages
> using it becomes small enough that a sufficiently motivated/bored/gullible
> person could take on the task of porting them all to a newer EAPI. EAPI 0 is
> our baseline (all EAPIs are defined as "EAPI 0 plus/minus foo") and thus
> should never* be removed.  Anything else is fair game.
> 
> 
> *for varying lengths of never.  If it becomes completely irrelevant then
> yeah just boot it.
> 



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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Rich Freeman]

On Wed, Oct 17, 2012 at 1:34 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> Would be easier to prune old versions if we "force" them to be less
> using at least preventing new ebuilds to use them. For example, what is
> the advantage for a new ebuild to still rely on old src_compile phase
> instead of src_prepare/configure...?

It can be bumped by copying it from the ebuild for the previous
version, thus introducing no errors.  Or maybe the person who authored
it (who might or might not even be a developer) isn't familiar with
the latest EAPI, but the code still works.

A policy that says all new ebuilds shall use EAPI foo might result in
fewer new ebuilds.  Sure, they'll have new and shiny fooness, but
arguably I'd rather have more packages supported on older EAPIs then
fewer packages supported on newer ones.

Again, as I stated before, things that actually benefit the end users
like slot dependencies are fine to mandate when it makes sense to do
so.

I think the whole developers-can't-handle-47-EAPIs thing is a red
herring.  The fact that there are packages written in Erlang in the
tree doesn't cause me any issues even though I haven't had to do any
work in Erlang.  If I ever wanted to maintain such a package then I'd
take the time to learn it as needed.  Likewise, if I wanted to
maintain a package that used EAPI joe and I really prefer to work in
EAPI fred, then I'd revise it at my next convenience.

Rich

[gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Ryan Hill]

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

On Wed, 17 Oct 2012 15:00:12 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, Oct 17, 2012 at 1:34 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Would be easier to prune old versions if we "force" them to be less
> > using at least preventing new ebuilds to use them. For example, what is
> > the advantage for a new ebuild to still rely on old src_compile phase
> > instead of src_prepare/configure...?
> 
> It can be bumped by copying it from the ebuild for the previous
> version, thus introducing no errors.

Yeah, someone could be making a small change (eg. adding a patch that
requires a revbump) to a package they don't maintain and aren't familiar
with.  Forcing them to port/rewrite the ebuild isn't going to make anyone
happy.

> I think the whole developers-can't-handle-47-EAPIs thing is a red
> herring.  The fact that there are packages written in Erlang in the
> tree doesn't cause me any issues even though I haven't had to do any
> work in Erlang.  If I ever wanted to maintain such a package then I'd
> take the time to learn it as needed.  Likewise, if I wanted to
> maintain a package that used EAPI joe and I really prefer to work in
> EAPI fred, then I'd revise it at my next convenience.

Well, it's not just about ebuilds you maintain.  Think about something
like the gcc-porting trackers where you have to touch a lot of ebuilds
across the tree.  You really do have to have a working knowledge of the
differences between EAPIs to do so.  My browser bookmark to the EAPI
cheatsheet is one of the more frequently used as it is.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Rich Freeman]

On Thu, Oct 18, 2012 at 12:07 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Wed, 17 Oct 2012 15:00:12 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> I think the whole developers-can't-handle-47-EAPIs thing is a red
>> herring.  The fact that there are packages written in Erlang in the
>> tree doesn't cause me any issues even though I haven't had to do any
>> work in Erlang.  If I ever wanted to maintain such a package then I'd
>> take the time to learn it as needed.  Likewise, if I wanted to
>> maintain a package that used EAPI joe and I really prefer to work in
>> EAPI fred, then I'd revise it at my next convenience.
>
> Well, it's not just about ebuilds you maintain.  Think about something
> like the gcc-porting trackers where you have to touch a lot of ebuilds
> across the tree.  You really do have to have a working knowledge of the
> differences between EAPIs to do so.  My browser bookmark to the EAPI
> cheatsheet is one of the more frequently used as it is.

Can't you just ask the maintainers to fix their ebuilds?  And if they
don't respond or at least cooperate, well, then treeclean them.  I
don't think that library maintainers should have to bend over
backwards to fix reverse dependencies, within reason.  If out of the
whole tree two packages are blocking an upgrade, give a deadline or
treeclean them.  If we have 47 bazillion packages that don't work on
the newer lib, then slot it and bug upstream.

I do agree that trying to auto-mangle ebuilds from 47 different EAPIs
doesn't make sense.  Just assign a bug to the maintainer saying "do
this to your ebuild, or get it on EAPI foo so that I can fix it, by
<date> or it is gone."  The deadline is important - I've seen a
pattern on -dev where bugs linger without deadlines for months, and
then a deadline of two days is imposed, and then a big flame war
breaks out.  Just set a deadline up-front and make it reasonable.

Rich

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El jue, 18-10-2012 a las 09:36 -0400, Rich Freeman escribió:
> On Thu, Oct 18, 2012 at 12:07 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> > On Wed, 17 Oct 2012 15:00:12 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >> I think the whole developers-can't-handle-47-EAPIs thing is a red
> >> herring.  The fact that there are packages written in Erlang in the
> >> tree doesn't cause me any issues even though I haven't had to do any
> >> work in Erlang.  If I ever wanted to maintain such a package then I'd
> >> take the time to learn it as needed.  Likewise, if I wanted to
> >> maintain a package that used EAPI joe and I really prefer to work in
> >> EAPI fred, then I'd revise it at my next convenience.
> >
> > Well, it's not just about ebuilds you maintain.  Think about something
> > like the gcc-porting trackers where you have to touch a lot of ebuilds
> > across the tree.  You really do have to have a working knowledge of the
> > differences between EAPIs to do so.  My browser bookmark to the EAPI
> > cheatsheet is one of the more frequently used as it is.
> 
> Can't you just ask the maintainers to fix their ebuilds?  And if they
> don't respond or at least cooperate, well, then treeclean them.  I
> don't think that library maintainers should have to bend over
> backwards to fix reverse dependencies, within reason.  If out of the
> whole tree two packages are blocking an upgrade, give a deadline or
> treeclean them.  If we have 47 bazillion packages that don't work on
> the newer lib, then slot it and bug upstream.
> 
> I do agree that trying to auto-mangle ebuilds from 47 different EAPIs
> doesn't make sense.  Just assign a bug to the maintainer saying "do
> this to your ebuild, or get it on EAPI foo so that I can fix it, by
> <date> or it is gone."  The deadline is important - I've seen a
> pattern on -dev where bugs linger without deadlines for months, and
> then a deadline of two days is imposed, and then a big flame war
> breaks out.  Just set a deadline up-front and make it reasonable.
> 
> Rich
> 
> 

I didn't think eapi4 features were still "unfamiliar" to so many
people... let's say, what about deprecating eapi1, 2 and 0 for newer
ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for
newer ebuilds (eapi3 changes look to be minor when compared with
eapi2) ?

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Rich Freeman]

On Thu, Oct 18, 2012 at 11:49 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> I didn't think eapi4 features were still "unfamiliar" to so many
> people... let's say, what about deprecating eapi1, 2 and 0 for newer
> ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for
> newer ebuilds (eapi3 changes look to be minor when compared with
> eapi2) ?

This still involves the issue that what would be simple ebuild bumps
turn into a need to make more substantial changes to an ebuild.

And the concern still exists that a policy that says all new ebuilds
shall use EAPI foo might result in fewer new ebuilds.  Sure, they'll
have new and shiny fooness, but arguably I'd rather have more packages
supported on older EAPIs then fewer packages supported on newer ones.

If migrating to newer EAPIs is so simple, why aren't more doing it already?

Rich

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El jue, 18-10-2012 a las 13:49 -0400, Rich Freeman escribió:
> On Thu, Oct 18, 2012 at 11:49 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > I didn't think eapi4 features were still "unfamiliar" to so many
> > people... let's say, what about deprecating eapi1, 2 and 0 for newer
> > ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for
> > newer ebuilds (eapi3 changes look to be minor when compared with
> > eapi2) ?
> 
> This still involves the issue that what would be simple ebuild bumps
> turn into a need to make more substantial changes to an ebuild.

But that changes will save us from needing to move a lot of ebuilds to
newer eapis if some years later we decide to deprecate some of them. For
example, if every package using eapi1 is forced to be bumped to newer
eapi, we won't need to manually do that work in the future if we decide
to deprecate old eapis. Also, it's probably better to force new ebuilds
to use things like splitted configure phase instead of keeping with old
eapi0/1 src_compile one, also the same for deprecated things like dosed
and dohard. If there were valid reasons to ban then on newer eapi, I
think it's better to not allow people to still use old eapi to skip that
banning (or were they banned only for cosmetic reasons?)

> 
> And the concern still exists that a policy that says all new ebuilds
> shall use EAPI foo might result in fewer new ebuilds.  Sure, they'll
> have new and shiny fooness, but arguably I'd rather have more packages
> supported on older EAPIs then fewer packages supported on newer ones.
> 
> If migrating to newer EAPIs is so simple, why aren't more doing it already?

Personally I see no major difficult in moving to eapi4, what exact
difficult are you (I mean people still sticking with eapi0/1) seeing? I
have re-read http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
and I can't see anything specially hard :/ 

> 
> Rich
> 
> 



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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Rich Freeman]

On Thu, Oct 18, 2012 at 3:05 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> Personally I see no major difficult in moving to eapi4, what exact
> difficult are you (I mean people still sticking with eapi0/1) seeing?

It is harder than cp.  :)

If I write a new ebuild I would always target the most recent EAPI.
However, if I'm just doing a revbump, why fix what ain't broken?

That is rhetorical.  I do understand your logic.  However, if it takes
me 15min to do something now, and it might take me 15min to do it
later, I'll take later every time since who knows if the package will
even be around later.

Rich

[gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Ryan Hill]

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

On Thu, 18 Oct 2012 09:36:27 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> > Well, it's not just about ebuilds you maintain.  Think about something
> > like the gcc-porting trackers where you have to touch a lot of ebuilds
> > across the tree.  You really do have to have a working knowledge of the
> > differences between EAPIs to do so.  My browser bookmark to the EAPI
> > cheatsheet is one of the more frequently used as it is.
> 
> Can't you just ask the maintainers to fix their ebuilds?  And if they
> don't respond or at least cooperate, well, then treeclean them.

Seriously, no you can't.  I think you greatly underestimate the number of
ebuilds in the tree that don't have an actual maintainer, and the
availability of maintainers for those that do.  If I had to wait for people
to fix stuff on their own we'd still be on gcc 4.4.

> I do agree that trying to auto-mangle ebuilds from 47 different EAPIs
> doesn't make sense.  Just assign a bug to the maintainer saying "do
> this to your ebuild, or get it on EAPI foo so that I can fix it, by
> <date> or it is gone."

So I can twiddle my thumbs for months waiting for something to happen or I
can take 2 minutes to look at the EAPI spec.

And I have absolutely no interest whatsoever in forcing people to update their
ebuilds just to suit my particular needs. They're the maintainer, they can
run their shop however they see fit.  I'm not going to try to get something
removed just because I can't be bothered to remember a few details.

Anyways, we're seriously getting off topic here.  I don't think anyone
objected to removing the EAPI 0 requirement for system packages (and in
reality no one follows it anyways.  Even portage is EAPI 3).


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Zac Medico]

On 10/18/2012 09:09 PM, Ryan Hill wrote:
> Anyways, we're seriously getting off topic here.  I don't think anyone
> objected to removing the EAPI 0 requirement for system packages (and in
> reality no one follows it anyways.

An EAPI 0 requirement for system packages is just silly these days.

>  Even portage is EAPI 3).

For the recored, stable portage is EAPI 2, and there wasn't much choice
in the matter since portage depends on python-2.6 which uses EAPI 2 (and
we don't want EAPI 0 or 1 package managers pulling in a portage which
depends on a python with an unsupported EAPI).
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El jue, 18-10-2012 a las 15:35 -0400, Rich Freeman escribió:
> On Thu, Oct 18, 2012 at 3:05 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Personally I see no major difficult in moving to eapi4, what exact
> > difficult are you (I mean people still sticking with eapi0/1) seeing?
> 
> It is harder than cp.  :)
> 
> If I write a new ebuild I would always target the most recent EAPI.
> However, if I'm just doing a revbump, why fix what ain't broken?
> 
> That is rhetorical.  I do understand your logic.  However, if it takes
> me 15min to do something now, and it might take me 15min to do it
> later, I'll take later every time since who knows if the package will
> even be around later.
> 
> Rich
> 
> 

It's not only about the difficulty problem (that I don't see so hard),
it also about keeping packages behaving inconsistently around the tree
due people keeping old eapis in their ebuilds:
- What will occur if people is not forced to use eapi5 when "slot
operator dependencies" are needed? Will people still need to already run
revdep-rebuild for ages to be safer?

- What about " --disable-silent-rules" eapi5 feature? Will we have part
of the tree passing that option while other packages are still showing
hidden output due old eapi usage?

- What about src_test behavior? If packages are broken they should force
-j1 for that packages... but if we don't push people to jump to last
eapi, they will be tempted to simply skip the eapi bump to hide the
problem.

- Look to different blockers handling introduced in eapi2, if people
keeps using older eapis, they will still make people to need to manually
unmerge old package even if not needed.

- Also look to packages still dying due unsatisfied USE dependencies
instead of bumping to eapi >=2 and setting that deps properly.

- And the different behavior of utilities dying, they will die on eapi4
but won't on older eapis and, then, that utils could still be not
running at all but that being hidden.

- Also the --disable-dependency-tracking parsing in eapi4, if it was
added to run configure faster, that is nice, but packages still wanting
to keep old eapi to not make the effort to bump it will still have a
slower configure run.

What I am trying to say is that, if we agree latest eapi is technically
better, we need to try to get it used when possible (I mean, when, for
example, eclasses are ported) for a "QA" reasoning.

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Alexis Ballier]

On Fri, 19 Oct 2012 19:21:52 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

[...]

> What I am trying to say is that, if we agree latest eapi is
> technically better, we need to try to get it used when possible (I
> mean, when, for example, eclasses are ported) for a "QA" reasoning.

i think we all agree that there are improvements in newer eapis.

what about filling bugs, preferably with patches, when such
improvements are really needed ? like what was done for nuking
built_with_use.

arguing to death if 'should use latest eapi' should become 'must use
latest eapi' will never get things done :)

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El vie, 19-10-2012 a las 14:51 -0300, Alexis Ballier escribió:
> On Fri, 19 Oct 2012 19:21:52 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> [...]
> 
> > What I am trying to say is that, if we agree latest eapi is
> > technically better, we need to try to get it used when possible (I
> > mean, when, for example, eclasses are ported) for a "QA" reasoning.
> 
> i think we all agree that there are improvements in newer eapis.
> 
> what about filling bugs, preferably with patches, when such
> improvements are really needed ? like what was done for nuking
> built_with_use.
> 
> arguing to death if 'should use latest eapi' should become 'must use
> latest eapi' will never get things done :)
> 
> 

Because it will add even more work, I mean:
- I catch a package using and old eapi and, then, still not passing
--disable-silent-rules option. => First problem, I need to notice that
package, there are packages I simply won't notice because I don't merge
them ever or, simply, I don't notice that option is not being used.

- I need to report a bug per each package using old eapi => I would need
to report a ton of bugs for bumping eapi that, probably, I could have
directly bumped myself if I would be allowed to (I already do it in my
maintained packages and maintainer-needed ones, but not for others as
maybe their maintainers dislike...)

- Maintainer need to check that bug and commit the change or reject the
bump (in that case we would be blocked if maintainer doesn't bump it for
some strange reason). There are also some devs really slow to reply.

- This effort needs to be done again and again in the future with newer
eapis, while could be "automatically" done on next bump by maintainer.



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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Alexis Ballier]

On Fri, 19 Oct 2012 20:09:15 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El vie, 19-10-2012 a las 14:51 -0300, Alexis Ballier escribió:
> > On Fri, 19 Oct 2012 19:21:52 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> > [...]
> > 
> > > What I am trying to say is that, if we agree latest eapi is
> > > technically better, we need to try to get it used when possible (I
> > > mean, when, for example, eclasses are ported) for a "QA"
> > > reasoning.
> > 
> > i think we all agree that there are improvements in newer eapis.
> > 
> > what about filling bugs, preferably with patches, when such
> > improvements are really needed ? like what was done for nuking
> > built_with_use.
> > 
> > arguing to death if 'should use latest eapi' should become 'must use
> > latest eapi' will never get things done :)
> > 
> > 
> 
> Because it will add even more work, I mean:
> - I catch a package using and old eapi and, then, still not passing
> --disable-silent-rules option. => First problem, I need to notice that
> package, there are packages I simply won't notice because I don't
> merge them ever or, simply, I don't notice that option is not being
> used.

i dont see that many blockers of bug #429308 ; it probably doesn't even
reach 1% of packages using old eapis. perhaps because silent rules are
not enabled by default afaik.

> - I need to report a bug per each package using old eapi => I would
> need to report a ton of bugs for bumping eapi that, probably, I could
> have directly bumped myself if I would be allowed to (I already do it
> in my maintained packages and maintainer-needed ones, but not for
> others as maybe their maintainers dislike...)
>
> - Maintainer need to check that bug and commit the change or reject
> the bump (in that case we would be blocked if maintainer doesn't bump
> it for some strange reason). There are also some devs really slow to
> reply.

filling a bug has one advantage you forgot: training fellow
developers. if you say simply bumping the eapi will get improvements for
free (whatever they are) to the maintainer, then she will be very happy
to bump it i'd guess and have learnt that its good practices to do so.

if you volunteer to do some conversions you can probably ask people to
grant you permission to convert their ebuilds.

[...]

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El vie, 19-10-2012 a las 15:47 -0300, Alexis Ballier escribió:
[...]
> > Because it will add even more work, I mean:
> > - I catch a package using and old eapi and, then, still not passing
> > --disable-silent-rules option. => First problem, I need to notice that
> > package, there are packages I simply won't notice because I don't
> > merge them ever or, simply, I don't notice that option is not being
> > used.
> 
> i dont see that many blockers of bug #429308 ; it probably doesn't even
> reach 1% of packages using old eapis. perhaps because silent rules are
> not enabled by default afaik.

It was only an example, anyway, I think bugs were stopped to be reported
due that option being suggested for eapi5 inclusion (and even older
eapis, but it was rejected if I don't misremember).

Think in other examples like --disable-dependency-tracking, I am talking
in general.

> 
> > - I need to report a bug per each package using old eapi => I would
> > need to report a ton of bugs for bumping eapi that, probably, I could
> > have directly bumped myself if I would be allowed to (I already do it
> > in my maintained packages and maintainer-needed ones, but not for
> > others as maybe their maintainers dislike...)
> >
> > - Maintainer need to check that bug and commit the change or reject
> > the bump (in that case we would be blocked if maintainer doesn't bump
> > it for some strange reason). There are also some devs really slow to
> > reply.
> 
> filling a bug has one advantage you forgot: training fellow
> developers. if you say simply bumping the eapi will get improvements for
> free (whatever they are) to the maintainer, then she will be very happy
> to bump it i'd guess and have learnt that its good practices to do so.
> 

I thought all developers should know how to manage eapis.


> if you volunteer to do some conversions you can probably ask people to
> grant you permission to convert their ebuilds.
> 
> [...]
> 

I volunteer to do whatever conversions you want for every ebuild I find
if I have time... what prevents me from doing it is to commit that
changes to ebuilds not maintained by me and not knowing if developers
agree on using latest eapi if possible. A more general solution (or
policy) needs to be worked as, otherwise, tree won't be moved to latest
eapi ever because we would need to:
- Periodically send bugs + patches
- Ask for permission to commit

And that for every eapi bump

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> I volunteer to do whatever conversions you want for every ebuild I find
> if I have time... what prevents me from doing it is to commit that
> changes to ebuilds not maintained by me and not knowing if developers
> agree on using latest eapi if possible. A more general solution (or
> policy) needs to be worked as, otherwise, tree won't be moved to latest
> eapi ever because we would need to:
> - Periodically send bugs + patches
> - Ask for permission to commit
> 
> And that for every eapi bump
> 

Either an ebuild has a responsive maintainer, which you can ask friendly
to bump the EAPI because of feature X you would like to use or there is
no maintainer, in which case you are free to touch/bump or last rite the
ebuild.

So i still dont see any need or requirement for a policy to
force/require all devs to always use or switch to the latest avaidable
EAPI. As already written in this thread, it would just mean less new
ebuilds and less version bumps with such a policy. And i also prefer
more work done with older EAPI versions around then less ebuilds/new
versions with latest EAPI.

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > I volunteer to do whatever conversions you want for every ebuild I find
> > if I have time... what prevents me from doing it is to commit that
> > changes to ebuilds not maintained by me and not knowing if developers
> > agree on using latest eapi if possible. A more general solution (or
> > policy) needs to be worked as, otherwise, tree won't be moved to latest
> > eapi ever because we would need to:
> > - Periodically send bugs + patches
> > - Ask for permission to commit
> > 
> > And that for every eapi bump
> > 
> 
> Either an ebuild has a responsive maintainer, which you can ask friendly
> to bump the EAPI because of feature X you would like to use or there is
> no maintainer, in which case you are free to touch/bump or last rite the
> ebuild.
> 
> So i still dont see any need or requirement for a policy to
> force/require all devs to always use or switch to the latest avaidable
> EAPI. As already written in this thread, it would just mean less new
> ebuilds and less version bumps with such a policy. And i also prefer
> more work done with older EAPI versions around then less ebuilds/new
> versions with latest EAPI.
> 

Seriously, what people is still having problems with handling eapi4? If
there are doubts about its usage, they should be asked and resolved
instead of ignored keeping ebuilds with older eapis. The only eapi that
probably adds no advantage for a lot of ebuilds is eapi3, but that is
not the case for eapi4 for example, that includes changes that should be
incorporated by most packages in the tree, some of them introduced by it
and others inherited from older eapis.

What is the advantage of using eapi2 over eapi4 for example? What "hard
to learn" change was included in eapi4 over eapi2?

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
>> Pacho Ramos schrieb:
>>> I volunteer to do whatever conversions you want for every ebuild I find
>>> if I have time... what prevents me from doing it is to commit that
>>> changes to ebuilds not maintained by me and not knowing if developers
>>> agree on using latest eapi if possible. A more general solution (or
>>> policy) needs to be worked as, otherwise, tree won't be moved to latest
>>> eapi ever because we would need to:
>>> - Periodically send bugs + patches
>>> - Ask for permission to commit
>>>
>>> And that for every eapi bump
>>>
>>
>> Either an ebuild has a responsive maintainer, which you can ask friendly
>> to bump the EAPI because of feature X you would like to use or there is
>> no maintainer, in which case you are free to touch/bump or last rite the
>> ebuild.
>>
>> So i still dont see any need or requirement for a policy to
>> force/require all devs to always use or switch to the latest avaidable
>> EAPI. As already written in this thread, it would just mean less new
>> ebuilds and less version bumps with such a policy. And i also prefer
>> more work done with older EAPI versions around then less ebuilds/new
>> versions with latest EAPI.
>>
> 
> Seriously, what people is still having problems with handling eapi4? If
> there are doubts about its usage, they should be asked and resolved
> instead of ignored keeping ebuilds with older eapis. The only eapi that
> probably adds no advantage for a lot of ebuilds is eapi3, but that is
> not the case for eapi4 for example, that includes changes that should be
> incorporated by most packages in the tree, some of them introduced by it
> and others inherited from older eapis.
> 
> What is the advantage of using eapi2 over eapi4 for example? What "hard
> to learn" change was included in eapi4 over eapi2?
> 

This is not about "having problems with handling eapi-X", this is just
about limited time and the choice where to spend that time. If you do
just a version bump, you often dont have to touch the ebuild at all,
just copy, test, commit and be happy. If you additionally require an
EAPI bump, this means to carefully check the ebuild, adjust it to the
new EAPI and additionally check, that the expected haviour is also the
one that happens. While doing this, i could also have fixed another bug
or have done another version bump. And that was already expressed in my
first response. I nowhere claimed to have problems with EAPI bumps, just
that they require additional time, so reducing the amount of time left
to create new ebuilds/fix bugs/do version bumps. And with the choice, i
prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched
to a new EAPI.

So my question to you: What is the advantage of using ${NEW_EAPI} over
using ${OLDER_EAPI}, when the ebuild does the same and the result is the
same?

-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Alexis Ballier]

On Fri, 19 Oct 2012 21:53:18 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> Seriously, what people is still having problems with handling eapi4?
> If there are doubts about its usage, they should be asked and resolved
> instead of ignored keeping ebuilds with older eapis. The only eapi
> that probably adds no advantage for a lot of ebuilds is eapi3, but
> that is not the case for eapi4 for example, that includes changes
> that should be incorporated by most packages in the tree, some of
> them introduced by it and others inherited from older eapis.
> 
> What is the advantage of using eapi2 over eapi4 for example? What
> "hard to learn" change was included in eapi4 over eapi2?

Were you around when eapi2 got out and we had a bunch of packages
running econf twice because we wanted to quickly get rid of
built_with_use?

A 5 mins fix is a 5 mins fix, if you include an eapi bump in those 5
mins then i expect crap to be committed to the tree or nothing at all.

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Rich Freeman]

On Fri, Oct 19, 2012 at 4:39 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> This is not about "having problems with handling eapi-X", this is just
> about limited time and the choice where to spend that time. If you do
> just a version bump, you often dont have to touch the ebuild at all,
> just copy, test, commit and be happy. If you additionally require an
> EAPI bump, this means to carefully check the ebuild, adjust it to the
> new EAPI and additionally check, that the expected haviour is also the
> one that happens. While doing this, i could also have fixed another bug
> or have done another version bump.

Or, more likely, you probably would just ignore the bug that requires
an EAPI bump and leave the existing buggy version in the tree.  Then
you'd go work on something where your time could be more effectively
spent.

I've seen this at work all the time - "raising the bar" on quality (as
measured by the pound of paperwork) often results in a lower quality
system, because fixing bugs is much more expensive so bugs simply
don't get fixed.

Somebody raised the issue of slot dependencies earlier.  I'm
completely for a policy that states that the entire tree should be
updated to take advantage of these where applicable.  I wouldn't state
it in terms of EAPI - I'd state it in terms of outcome.  Make it a
general call for action, and then after so much time have bugs filed
when packages do not comply.  I'd love to see Gentoo reach a point
soon where users don't have to run revdep-rebuild.

Focusing on outcomes is what I'm all about - forget about EAPIs -
focus on what it is that we really want, and make those things that
really matter.

Rich

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
> >> Pacho Ramos schrieb:
> >>> I volunteer to do whatever conversions you want for every ebuild I find
> >>> if I have time... what prevents me from doing it is to commit that
> >>> changes to ebuilds not maintained by me and not knowing if developers
> >>> agree on using latest eapi if possible. A more general solution (or
> >>> policy) needs to be worked as, otherwise, tree won't be moved to latest
> >>> eapi ever because we would need to:
> >>> - Periodically send bugs + patches
> >>> - Ask for permission to commit
> >>>
> >>> And that for every eapi bump
> >>>
> >>
> >> Either an ebuild has a responsive maintainer, which you can ask friendly
> >> to bump the EAPI because of feature X you would like to use or there is
> >> no maintainer, in which case you are free to touch/bump or last rite the
> >> ebuild.
> >>
> >> So i still dont see any need or requirement for a policy to
> >> force/require all devs to always use or switch to the latest avaidable
> >> EAPI. As already written in this thread, it would just mean less new
> >> ebuilds and less version bumps with such a policy. And i also prefer
> >> more work done with older EAPI versions around then less ebuilds/new
> >> versions with latest EAPI.
> >>
> > 
> > Seriously, what people is still having problems with handling eapi4? If
> > there are doubts about its usage, they should be asked and resolved
> > instead of ignored keeping ebuilds with older eapis. The only eapi that
> > probably adds no advantage for a lot of ebuilds is eapi3, but that is
> > not the case for eapi4 for example, that includes changes that should be
> > incorporated by most packages in the tree, some of them introduced by it
> > and others inherited from older eapis.
> > 
> > What is the advantage of using eapi2 over eapi4 for example? What "hard
> > to learn" change was included in eapi4 over eapi2?
> > 
> 
> This is not about "having problems with handling eapi-X", this is just
> about limited time and the choice where to spend that time. If you do
> just a version bump, you often dont have to touch the ebuild at all,
> just copy, test, commit and be happy. If you additionally require an
> EAPI bump, this means to carefully check the ebuild, adjust it to the
> new EAPI and additionally check, that the expected haviour is also the
> one that happens. While doing this, i could also have fixed another bug
> or have done another version bump. And that was already expressed in my
> first response. I nowhere claimed to have problems with EAPI bumps, just
> that they require additional time, so reducing the amount of time left
> to create new ebuilds/fix bugs/do version bumps. And with the choice, i
> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched
> to a new EAPI.
> 
> So my question to you: What is the advantage of using ${NEW_EAPI} over
> using ${OLDER_EAPI}, when the ebuild does the same and the result is the
> same?
> 

I already explained the advantages, simply take a look to:
http://devmanual.gentoo.org/ebuild-writing/eapi/index.html

to see that, for example, --disable-dependency-tracking won't be used by
default for older eapis. The same will occur with eapi5 and
--disable-silent-rules or running tests in parallel.

That time you think you are saving, will be need to be lost if, for
example, some QA policy appears in the future to move to try to run
tests in parallel when possible, or force verbose output.

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El vie, 19-10-2012 a las 17:43 -0300, Alexis Ballier escribió:
> On Fri, 19 Oct 2012 21:53:18 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > Seriously, what people is still having problems with handling eapi4?
> > If there are doubts about its usage, they should be asked and resolved
> > instead of ignored keeping ebuilds with older eapis. The only eapi
> > that probably adds no advantage for a lot of ebuilds is eapi3, but
> > that is not the case for eapi4 for example, that includes changes
> > that should be incorporated by most packages in the tree, some of
> > them introduced by it and others inherited from older eapis.
> > 
> > What is the advantage of using eapi2 over eapi4 for example? What
> > "hard to learn" change was included in eapi4 over eapi2?
> 
> Were you around when eapi2 got out and we had a bunch of packages
> running econf twice because we wanted to quickly get rid of
> built_with_use?
> 
> A 5 mins fix is a 5 mins fix, if you include an eapi bump in those 5
> mins then i expect crap to be committed to the tree or nothing at all.
> 
> 

Of course the idea wouldn't be to deprecate older eapis as soon as newer
one is released but, for example, do you really think forcing people to
use eapi4 now would cause so many problems? We could even create a team
(I would join to that one of course) to help in migration process.

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Michał Górny]

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

On Sat, 20 Oct 2012 08:07:39 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El vie, 19-10-2012 a las 17:43 -0300, Alexis Ballier escribió:
> > On Fri, 19 Oct 2012 21:53:18 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> > > Seriously, what people is still having problems with handling eapi4?
> > > If there are doubts about its usage, they should be asked and resolved
> > > instead of ignored keeping ebuilds with older eapis. The only eapi
> > > that probably adds no advantage for a lot of ebuilds is eapi3, but
> > > that is not the case for eapi4 for example, that includes changes
> > > that should be incorporated by most packages in the tree, some of
> > > them introduced by it and others inherited from older eapis.
> > > 
> > > What is the advantage of using eapi2 over eapi4 for example? What
> > > "hard to learn" change was included in eapi4 over eapi2?
> > 
> > Were you around when eapi2 got out and we had a bunch of packages
> > running econf twice because we wanted to quickly get rid of
> > built_with_use?
> > 
> > A 5 mins fix is a 5 mins fix, if you include an eapi bump in those 5
> > mins then i expect crap to be committed to the tree or nothing at all.
> 
> Of course the idea wouldn't be to deprecate older eapis as soon as newer
> one is released but, for example, do you really think forcing people to
> use eapi4 now would cause so many problems? We could even create a team
> (I would join to that one of course) to help in migration process.

Well, creating a team dedicated to the cause is a good idea anyway.
Without a policy or anything like that, the team could at least work on
improving compatibility of eclasses with new EAPIs.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El sáb, 20-10-2012 a las 08:14 +0200, Michał Górny escribió:
> On Sat, 20 Oct 2012 08:07:39 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El vie, 19-10-2012 a las 17:43 -0300, Alexis Ballier escribió:
> > > On Fri, 19 Oct 2012 21:53:18 +0200
> > > Pacho Ramos <pacho@gentoo.org> wrote:
> > > 
> > > > Seriously, what people is still having problems with handling eapi4?
> > > > If there are doubts about its usage, they should be asked and resolved
> > > > instead of ignored keeping ebuilds with older eapis. The only eapi
> > > > that probably adds no advantage for a lot of ebuilds is eapi3, but
> > > > that is not the case for eapi4 for example, that includes changes
> > > > that should be incorporated by most packages in the tree, some of
> > > > them introduced by it and others inherited from older eapis.
> > > > 
> > > > What is the advantage of using eapi2 over eapi4 for example? What
> > > > "hard to learn" change was included in eapi4 over eapi2?
> > > 
> > > Were you around when eapi2 got out and we had a bunch of packages
> > > running econf twice because we wanted to quickly get rid of
> > > built_with_use?
> > > 
> > > A 5 mins fix is a 5 mins fix, if you include an eapi bump in those 5
> > > mins then i expect crap to be committed to the tree or nothing at all.
> > 
> > Of course the idea wouldn't be to deprecate older eapis as soon as newer
> > one is released but, for example, do you really think forcing people to
> > use eapi4 now would cause so many problems? We could even create a team
> > (I would join to that one of course) to help in migration process.
> 
> Well, creating a team dedicated to the cause is a good idea anyway.
> Without a policy or anything like that, the team could at least work on
> improving compatibility of eclasses with new EAPIs.
> 

Yes, fine

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribió:
>> Pacho Ramos schrieb:
>>> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
>>>> Pacho Ramos schrieb:
>>>>> I volunteer to do whatever conversions you want for every ebuild I find
>>>>> if I have time... what prevents me from doing it is to commit that
>>>>> changes to ebuilds not maintained by me and not knowing if developers
>>>>> agree on using latest eapi if possible. A more general solution (or
>>>>> policy) needs to be worked as, otherwise, tree won't be moved to latest
>>>>> eapi ever because we would need to:
>>>>> - Periodically send bugs + patches
>>>>> - Ask for permission to commit
>>>>>
>>>>> And that for every eapi bump
>>>>>
>>>>
>>>> Either an ebuild has a responsive maintainer, which you can ask friendly
>>>> to bump the EAPI because of feature X you would like to use or there is
>>>> no maintainer, in which case you are free to touch/bump or last rite the
>>>> ebuild.
>>>>
>>>> So i still dont see any need or requirement for a policy to
>>>> force/require all devs to always use or switch to the latest avaidable
>>>> EAPI. As already written in this thread, it would just mean less new
>>>> ebuilds and less version bumps with such a policy. And i also prefer
>>>> more work done with older EAPI versions around then less ebuilds/new
>>>> versions with latest EAPI.
>>>>
>>>
>>> Seriously, what people is still having problems with handling eapi4? If
>>> there are doubts about its usage, they should be asked and resolved
>>> instead of ignored keeping ebuilds with older eapis. The only eapi that
>>> probably adds no advantage for a lot of ebuilds is eapi3, but that is
>>> not the case for eapi4 for example, that includes changes that should be
>>> incorporated by most packages in the tree, some of them introduced by it
>>> and others inherited from older eapis.
>>>
>>> What is the advantage of using eapi2 over eapi4 for example? What "hard
>>> to learn" change was included in eapi4 over eapi2?
>>>
>>
>> This is not about "having problems with handling eapi-X", this is just
>> about limited time and the choice where to spend that time. If you do
>> just a version bump, you often dont have to touch the ebuild at all,
>> just copy, test, commit and be happy. If you additionally require an
>> EAPI bump, this means to carefully check the ebuild, adjust it to the
>> new EAPI and additionally check, that the expected haviour is also the
>> one that happens. While doing this, i could also have fixed another bug
>> or have done another version bump. And that was already expressed in my
>> first response. I nowhere claimed to have problems with EAPI bumps, just
>> that they require additional time, so reducing the amount of time left
>> to create new ebuilds/fix bugs/do version bumps. And with the choice, i
>> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched
>> to a new EAPI.
>>
>> So my question to you: What is the advantage of using ${NEW_EAPI} over
>> using ${OLDER_EAPI}, when the ebuild does the same and the result is the
>> same?
>>
> 
> I already explained the advantages, simply take a look to:
> http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
> 
> to see that, for example, --disable-dependency-tracking won't be used by
> default for older eapis. The same will occur with eapi5 and
> --disable-silent-rules or running tests in parallel.
> 
> That time you think you are saving, will be need to be lost if, for
> example, some QA policy appears in the future to move to try to run
> tests in parallel when possible, or force verbose output.
> 

Please remember, that not every package out there does use an autotools
based build system, we also have custom configure scripts, custom
makefiles, things like cmake, qmake or even completly different things
like ant based build systems for java. All those build systems wont
benefit neither from --disable-dependency-tracking nor from
--disable-silent-rules.

Also, as already pointed out, a package, which currently exists may be
unmaintained and useless in the future, so if i dont do the work now and
remove the then unneeded package later, i did not spend any additional
time for this change. Your requirement would either mean wasted time or
another open bug until the package gets removed.

Beside that, i did ask you about the case, where "the ebuild does the
same and the result is the same". And you did not answer my question,
why an EAPI-bump in such cases should be done.

And finally, as already pointed out by Rich, you should not talk about
any specific EAPI you like/prefer/want to be used everyhwere, but
instead about the issue you want to solve. So just point out the issue
and ask the maintainer to fix it. If he uses a newer EAPI, good. If he
uses another solution, which also fixes the issue, also good. We should
not discuss about a specific way to solve some issues, since this is the
maintainers choice. Our goal should instead be to fix as many issues as
possible with our limited amount of time we have for Gentoo.


-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El sáb, 20-10-2012 a las 16:09 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribió:
> >> Pacho Ramos schrieb:
> >>> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
> >>>> Pacho Ramos schrieb:
> >>>>> I volunteer to do whatever conversions you want for every ebuild I find
> >>>>> if I have time... what prevents me from doing it is to commit that
> >>>>> changes to ebuilds not maintained by me and not knowing if developers
> >>>>> agree on using latest eapi if possible. A more general solution (or
> >>>>> policy) needs to be worked as, otherwise, tree won't be moved to latest
> >>>>> eapi ever because we would need to:
> >>>>> - Periodically send bugs + patches
> >>>>> - Ask for permission to commit
> >>>>>
> >>>>> And that for every eapi bump
> >>>>>
> >>>>
> >>>> Either an ebuild has a responsive maintainer, which you can ask friendly
> >>>> to bump the EAPI because of feature X you would like to use or there is
> >>>> no maintainer, in which case you are free to touch/bump or last rite the
> >>>> ebuild.
> >>>>
> >>>> So i still dont see any need or requirement for a policy to
> >>>> force/require all devs to always use or switch to the latest avaidable
> >>>> EAPI. As already written in this thread, it would just mean less new
> >>>> ebuilds and less version bumps with such a policy. And i also prefer
> >>>> more work done with older EAPI versions around then less ebuilds/new
> >>>> versions with latest EAPI.
> >>>>
> >>>
> >>> Seriously, what people is still having problems with handling eapi4? If
> >>> there are doubts about its usage, they should be asked and resolved
> >>> instead of ignored keeping ebuilds with older eapis. The only eapi that
> >>> probably adds no advantage for a lot of ebuilds is eapi3, but that is
> >>> not the case for eapi4 for example, that includes changes that should be
> >>> incorporated by most packages in the tree, some of them introduced by it
> >>> and others inherited from older eapis.
> >>>
> >>> What is the advantage of using eapi2 over eapi4 for example? What "hard
> >>> to learn" change was included in eapi4 over eapi2?
> >>>
> >>
> >> This is not about "having problems with handling eapi-X", this is just
> >> about limited time and the choice where to spend that time. If you do
> >> just a version bump, you often dont have to touch the ebuild at all,
> >> just copy, test, commit and be happy. If you additionally require an
> >> EAPI bump, this means to carefully check the ebuild, adjust it to the
> >> new EAPI and additionally check, that the expected haviour is also the
> >> one that happens. While doing this, i could also have fixed another bug
> >> or have done another version bump. And that was already expressed in my
> >> first response. I nowhere claimed to have problems with EAPI bumps, just
> >> that they require additional time, so reducing the amount of time left
> >> to create new ebuilds/fix bugs/do version bumps. And with the choice, i
> >> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched
> >> to a new EAPI.
> >>
> >> So my question to you: What is the advantage of using ${NEW_EAPI} over
> >> using ${OLDER_EAPI}, when the ebuild does the same and the result is the
> >> same?
> >>
> > 
> > I already explained the advantages, simply take a look to:
> > http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
> > 
> > to see that, for example, --disable-dependency-tracking won't be used by
> > default for older eapis. The same will occur with eapi5 and
> > --disable-silent-rules or running tests in parallel.
> > 
> > That time you think you are saving, will be need to be lost if, for
> > example, some QA policy appears in the future to move to try to run
> > tests in parallel when possible, or force verbose output.
> > 
> 
> Please remember, that not every package out there does use an autotools
> based build system, we also have custom configure scripts, custom
> makefiles, things like cmake, qmake or even completly different things
> like ant based build systems for java. All those build systems wont
> benefit neither from --disable-dependency-tracking nor from
> --disable-silent-rules.
> 
> Also, as already pointed out, a package, which currently exists may be
> unmaintained and useless in the future, so if i dont do the work now and
> remove the then unneeded package later, i did not spend any additional
> time for this change. Your requirement would either mean wasted time or
> another open bug until the package gets removed.

If the package is unmaintained it won't probably have a revision bump
and, then, eapi won't change, if any other needs to fix another bug and
also bumps eapi, that package will be enhanced, that is what really
matters. If it's broke because dev bumping it failed to bump the eapi,
lets fix it (or ask for help) to prevent him from doing that error
again. All are gains: package is improved and developer learns how to
handle new eapi

> 
> Beside that, i did ask you about the case, where "the ebuild does the
> same and the result is the same". And you did not answer my question,
> why an EAPI-bump in such cases should be done.

What about the huge number of packages that would benefit from the bump?
Why ignore them because a few packages won't benefit. Think in changes
like src_configure phase addition, that most packages with benefit from
it. Also, this is not about blindly forcing people to use latest eapi
without even evaluating what improvements they have, this is about, for
example, forcing packages to use eapi4 because it includes a ton of
enhancements from eapi0 that most packages would benefit from.

> 
> And finally, as already pointed out by Rich, you should not talk about
> any specific EAPI you like/prefer/want to be used everyhwere, but
> instead about the issue you want to solve. So just point out the issue
> and ask the maintainer to fix it. If he uses a newer EAPI, good. If he
> uses another solution, which also fixes the issue, also good. We should
> not discuss about a specific way to solve some issues, since this is the
> maintainers choice. Our goal should instead be to fix as many issues as
> possible with our limited amount of time we have for Gentoo.
> 
> 

I have already pointed multiple examples where bumping eapi will help to
improve things, not doing so because of that hypothetical problems you
think could occur only leads us to current situation: a ton of autotools
packages won't get --disable-silent-rules/--disable-dependency-tracking
improvements because people doesn't even try to bump eapi, some more
packages will hide utilities failing but not dying because of using old
eapis, inconsistent blockers handling around the tree due using
different eapis, packages still relying on dying in pkg_setup instead of
setting proper USE deps, packages still using dohard and dosed, html
files in /usr/share/doc being compressed because of old eapi usage, I
even noticed past week a package still using ebeep.

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Peter Stuge]

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

Pacho Ramos wrote:
> Seriously, what people is still having problems with handling eapi4?

Seriously, what people are still having problems with trimming quotes?


Pacho, I wrote a sarcastic manual for you about how to trim quotes in
your replies on the mailing list, but you are still not doing it.
This is incredibly surprising to me.


//Peter

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El sáb, 20-10-2012 a las 16:29 +0200, Pacho Ramos escribió:
[...]
> > And finally, as already pointed out by Rich, you should not talk about
> > any specific EAPI you like/prefer/want to be used everyhwere, but
> > instead about the issue you want to solve. So just point out the issue
> > and ask the maintainer to fix it. If he uses a newer EAPI, good. If he
> > uses another solution, which also fixes the issue, also good. We should
> > not discuss about a specific way to solve some issues, since this is the
> > maintainers choice. Our goal should instead be to fix as many issues as
> > possible with our limited amount of time we have for Gentoo.
> > 
> > 
> 
> I have already pointed multiple examples where bumping eapi will help to
> improve things, not doing so because of that hypothetical problems you
> think could occur only leads us to current situation: a ton of autotools
> packages won't get --disable-silent-rules/--disable-dependency-tracking
> improvements because people doesn't even try to bump eapi, some more
> packages will hide utilities failing but not dying because of using old
> eapis, inconsistent blockers handling around the tree due using
> different eapis, packages still relying on dying in pkg_setup instead of
> setting proper USE deps, packages still using dohard and dosed, html
> files in /usr/share/doc being compressed because of old eapi usage, I
> even noticed past week a package still using ebeep.

Another case: all packages should benefit from mtimes preserving for
installed files since eapi3

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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El sáb, 20-10-2012 a las 16:09 +0200, Thomas Sachau escribió:
>> Pacho Ramos schrieb:
>>> El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribió:
>>>> Pacho Ramos schrieb:
>>>>> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
>>>>>> Pacho Ramos schrieb:
>>>>>>> I volunteer to do whatever conversions you want for every ebuild I find
>>>>>>> if I have time... what prevents me from doing it is to commit that
>>>>>>> changes to ebuilds not maintained by me and not knowing if developers
>>>>>>> agree on using latest eapi if possible. A more general solution (or
>>>>>>> policy) needs to be worked as, otherwise, tree won't be moved to latest
>>>>>>> eapi ever because we would need to:
>>>>>>> - Periodically send bugs + patches
>>>>>>> - Ask for permission to commit
>>>>>>>
>>>>>>> And that for every eapi bump
>>>>>>>
>>>>>>
>>>>>> Either an ebuild has a responsive maintainer, which you can ask friendly
>>>>>> to bump the EAPI because of feature X you would like to use or there is
>>>>>> no maintainer, in which case you are free to touch/bump or last rite the
>>>>>> ebuild.
>>>>>>
>>>>>> So i still dont see any need or requirement for a policy to
>>>>>> force/require all devs to always use or switch to the latest avaidable
>>>>>> EAPI. As already written in this thread, it would just mean less new
>>>>>> ebuilds and less version bumps with such a policy. And i also prefer
>>>>>> more work done with older EAPI versions around then less ebuilds/new
>>>>>> versions with latest EAPI.
>>>>>>
>>>>>
>>>>> Seriously, what people is still having problems with handling eapi4? If
>>>>> there are doubts about its usage, they should be asked and resolved
>>>>> instead of ignored keeping ebuilds with older eapis. The only eapi that
>>>>> probably adds no advantage for a lot of ebuilds is eapi3, but that is
>>>>> not the case for eapi4 for example, that includes changes that should be
>>>>> incorporated by most packages in the tree, some of them introduced by it
>>>>> and others inherited from older eapis.
>>>>>
>>>>> What is the advantage of using eapi2 over eapi4 for example? What "hard
>>>>> to learn" change was included in eapi4 over eapi2?
>>>>>
>>>>
>>>> This is not about "having problems with handling eapi-X", this is just
>>>> about limited time and the choice where to spend that time. If you do
>>>> just a version bump, you often dont have to touch the ebuild at all,
>>>> just copy, test, commit and be happy. If you additionally require an
>>>> EAPI bump, this means to carefully check the ebuild, adjust it to the
>>>> new EAPI and additionally check, that the expected haviour is also the
>>>> one that happens. While doing this, i could also have fixed another bug
>>>> or have done another version bump. And that was already expressed in my
>>>> first response. I nowhere claimed to have problems with EAPI bumps, just
>>>> that they require additional time, so reducing the amount of time left
>>>> to create new ebuilds/fix bugs/do version bumps. And with the choice, i
>>>> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched
>>>> to a new EAPI.
>>>>
>>>> So my question to you: What is the advantage of using ${NEW_EAPI} over
>>>> using ${OLDER_EAPI}, when the ebuild does the same and the result is the
>>>> same?
>>>>
>>>
>>> I already explained the advantages, simply take a look to:
>>> http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
>>>
>>> to see that, for example, --disable-dependency-tracking won't be used by
>>> default for older eapis. The same will occur with eapi5 and
>>> --disable-silent-rules or running tests in parallel.
>>>
>>> That time you think you are saving, will be need to be lost if, for
>>> example, some QA policy appears in the future to move to try to run
>>> tests in parallel when possible, or force verbose output.
>>>
>>
>> Please remember, that not every package out there does use an autotools
>> based build system, we also have custom configure scripts, custom
>> makefiles, things like cmake, qmake or even completly different things
>> like ant based build systems for java. All those build systems wont
>> benefit neither from --disable-dependency-tracking nor from
>> --disable-silent-rules.
>>
>> Also, as already pointed out, a package, which currently exists may be
>> unmaintained and useless in the future, so if i dont do the work now and
>> remove the then unneeded package later, i did not spend any additional
>> time for this change. Your requirement would either mean wasted time or
>> another open bug until the package gets removed.
> 
> If the package is unmaintained it won't probably have a revision bump
> and, then, eapi won't change, if any other needs to fix another bug and
> also bumps eapi, that package will be enhanced, that is what really
> matters. If it's broke because dev bumping it failed to bump the eapi,
> lets fix it (or ask for help) to prevent him from doing that error
> again. All are gains: package is improved and developer learns how to
> handle new eapi

Hope you dont mix threads, since i dont see any relation between a
package being unmaintained, a revision bump and a changing EAPI.

Beside that:

A package not using the latest EAPI is not broken, please stop doing
such claims. Additionally fixing an issue without also bumping the
package to the latest EAPI is not an issue or error by itself either.

> 
>>
>> Beside that, i did ask you about the case, where "the ebuild does the
>> same and the result is the same". And you did not answer my question,
>> why an EAPI-bump in such cases should be done.
> 
> What about the huge number of packages that would benefit from the bump?
> Why ignore them because a few packages won't benefit. Think in changes
> like src_configure phase addition, that most packages with benefit from
> it. Also, this is not about blindly forcing people to use latest eapi
> without even evaluating what improvements they have, this is about, for
> example, forcing packages to use eapi4 because it includes a ton of
> enhancements from eapi0 that most packages would benefit from.
> 
>>
>> And finally, as already pointed out by Rich, you should not talk about
>> any specific EAPI you like/prefer/want to be used everyhwere, but
>> instead about the issue you want to solve. So just point out the issue
>> and ask the maintainer to fix it. If he uses a newer EAPI, good. If he
>> uses another solution, which also fixes the issue, also good. We should
>> not discuss about a specific way to solve some issues, since this is the
>> maintainers choice. Our goal should instead be to fix as many issues as
>> possible with our limited amount of time we have for Gentoo.
>>
>>
> 
> I have already pointed multiple examples where bumping eapi will help to
> improve things, not doing so because of that hypothetical problems you
> think could occur only leads us to current situation: a ton of autotools
> packages won't get --disable-silent-rules/--disable-dependency-tracking
> improvements because people doesn't even try to bump eapi, some more
> packages will hide utilities failing but not dying because of using old
> eapis, inconsistent blockers handling around the tree due using
> different eapis, packages still relying on dying in pkg_setup instead of
> setting proper USE deps, packages still using dohard and dosed, html
> files in /usr/share/doc being compressed because of old eapi usage, I
> even noticed past week a package still using ebeep.

I am not talking about hypothetical problems, i am talking about a real
thing: my limited amount of free time i am able and willing to spend for
Gentoo. And i prefer spending it on fixing real bugs over spending
additional time to bump the EAPI just for fun.

For the points you see issues with:
- dont miss, that one can also add those configure options in an ebuild
without the requirement to use the EAPI.
-Utilities failing but not dying? Only certain helper functions will die
with EAPI-4, nothing else. And if in doubt, just add a " || die" after
every call and be done with it. So also not related to the EAPI.
-blocker handling is done by the PM, not the ebuild, so if you have a
patch for a better UI output, PM maintainers will probably happily apply
it, when you provide it.
-for a die in pkg_setup instead of a USE dependency: Both ways will
prevent you from continuing, the second one only has a unified UI.
-I dont see any real problem with dosed and dohard, they are just
wrappers around sed and ln, so what would improve if someone replaces
the wrappers with calls to the wrapped tools?

We could continue forever with this examples, so i will shorten my point
of view:

If i want/need an option, i will add it to the ebuild. If an option i
want requires a newer EAPI, i will use the newer EAPI. If the current
EAPI does offer all i need, i wont spend any additional time on the EAPI
bump.

If you want to do it differently for the packages you maintain, fine.
Just dont try to force your preferred EAPI-handling on everyone else.


-- 

Thomas Sachau
Gentoo Linux Developer


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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El sáb, 20-10-2012 a las 16:09 +0200, Thomas Sachau escribió:
[...]
> And finally, as already pointed out by Rich, you should not talk about
> any specific EAPI you like/prefer/want to be used everyhwere, but
> instead about the issue you want to solve. So just point out the issue
> and ask the maintainer to fix it. If he uses a newer EAPI, good. If he
> uses another solution, which also fixes the issue, also good. We should
> not discuss about a specific way to solve some issues, since this is the
> maintainers choice. Our goal should instead be to fix as many issues as
> possible with our limited amount of time we have for Gentoo.
> 
> 

Also, I see your point, the problem is:
- Do we agree we should move to packages with splitted
src_configure/prepare phases? In that case eapi >=2 should be enforced.
- Do we agree mtimes should be preserved? In that case eapi >=3 should
be pushed because all ebuilds will use that enhancement.

Regarding other issues like --disable-dependency-tracking, do you know
any way to automate a check for knowing if a package that could benefit
from it (one using autotools) could pass it or not? If such a check
could exist, then, we would be able to only move that packages to newer
eapi (or pass option manually) and that would be enough to me. The same
would occur with --disable-silent-rules.

Please take care I am not trying to get latest eapi used per se, it's
because I want to see all new packages using, for example, splitted
src_compile phases, or preserved mtimes, or
--disable-dependency-tracking being passed on packages that could use
it. I thought the easiest way to do that automatically would be to try
to always use latest eapi and, then, that packages would be fixed
progressively. On the other hand, if you think the other way would be
easier, fine, but I wasn't sure how to, for example, check for the
--disable-dependency-tracking problem, or check that every package
needing revdep-rebuild will be moved to eapi5... 


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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

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

El sáb, 20-10-2012 a las 17:15 +0200, Thomas Sachau escribió:
[...]
> I am not talking about hypothetical problems, i am talking about a real
> thing: my limited amount of free time i am able and willing to spend for
> Gentoo. And i prefer spending it on fixing real bugs over spending
> additional time to bump the EAPI just for fun.
> 
> For the points you see issues with:
> - dont miss, that one can also add those configure options in an ebuild
> without the requirement to use the EAPI.
> -Utilities failing but not dying? Only certain helper functions will die
> with EAPI-4, nothing else. And if in doubt, just add a " || die" after
> every call and be done with it. So also not related to the EAPI.
> -blocker handling is done by the PM, not the ebuild, so if you have a
> patch for a better UI output, PM maintainers will probably happily apply
> it, when you provide it.
> -for a die in pkg_setup instead of a USE dependency: Both ways will
> prevent you from continuing, the second one only has a unified UI.
> -I dont see any real problem with dosed and dohard, they are just
> wrappers around sed and ln, so what would improve if someone replaces
> the wrappers with calls to the wrapped tools?
> 
> We could continue forever with this examples, so i will shorten my point
> of view:
> 
> If i want/need an option, i will add it to the ebuild. If an option i
> want requires a newer EAPI, i will use the newer EAPI. If the current
> EAPI does offer all i need, i wont spend any additional time on the EAPI
> bump.
> 
> If you want to do it differently for the packages you maintain, fine.
> Just dont try to force your preferred EAPI-handling on everyone else.
> 
> 

It's not just for fun, I have just replied to you in other mail, hope it
helps to explain better my position and why I thought bumping eapi would
be better.


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

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Rich Freeman]

On Sat, Oct 20, 2012 at 2:04 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> That time you think you are saving, will be need to be lost if, for
> example, some QA policy appears in the future to move to try to run
> tests in parallel when possible, or force verbose output.

So you're suggesting that I should invest 15 minutes of my time now so
that I MIGHT not have to invest 15 minutes of my time later?  And that
I should continue to invest 15 minutes every time a new EAPI comes
along?

That's like asking a banker to give you $5 now, so that in a year or
two you might be able to give them $5 back.

If we are going to tell people to do something NOW then there should
be a tangible benefit NOW, or at least on some reasonably near date
you can actually identify.

For packages where users get some immediate benefit from an EAPI bump
I'm all for pushing for them.  However, I wouldn't name the project
the "Tree Wide EAPI4 bump."  Instead I'd call it the "Tree Wide
Parallel Testing Initiative" or "Eliminate Revdep-rebuild Bonanza" or
whatever.

Yes, I realize that sometimes A has to happen before B, and I'm not
suggesting that we can't plan ahead.  However, we should be planning
ahead for something in particular, and actually have the plan.  It
does us no good to have a "Tree Wide Parallel Testing Initiative" if
somebody else isn't at least working on the "Tree Wide Parallel
Testing Tinderbox."

If all you're telling me is that I should spend 15 min bumping to EAPI
2, then 3, then 4, so that eventually I won't have to spend 15 min
upgrading from EAPI 2 straight to 7, I can't really see the point.

Rich

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El sáb, 20-10-2012 a las 16:09 +0200, Thomas Sachau escribió:
> [...]
>> And finally, as already pointed out by Rich, you should not talk about
>> any specific EAPI you like/prefer/want to be used everyhwere, but
>> instead about the issue you want to solve. So just point out the issue
>> and ask the maintainer to fix it. If he uses a newer EAPI, good. If he
>> uses another solution, which also fixes the issue, also good. We should
>> not discuss about a specific way to solve some issues, since this is the
>> maintainers choice. Our goal should instead be to fix as many issues as
>> possible with our limited amount of time we have for Gentoo.
>>
>>
> 
> Also, I see your point, the problem is:
> - Do we agree we should move to packages with splitted
> src_configure/prepare phases? In that case eapi >=2 should be enforced.

I see no need for EAPI>=2 enforcement. The main advantage here is mostly
the saved second default line from src_unpack/src_compile. This does not
outweight the additional work for the EAPI-change.

> - Do we agree mtimes should be preserved? In that case eapi >=3 should
> be pushed because all ebuilds will use that enhancement.

If a package has issues with not preserved mtimes, sure, bump it to
EAPI>=3 to fix the issue. In any other case, there is no advantage at
all for the additional work.

> Regarding other issues like --disable-dependency-tracking, do you know
> any way to automate a check for knowing if a package that could benefit
> from it (one using autotools) could pass it or not? If such a check
> could exist, then, we would be able to only move that packages to newer
> eapi (or pass option manually) and that would be enough to me. The same
> would occur with --disable-silent-rules.

Either ask our tinderbox users to do a full tree check or do such
tinderbox setup/run yourself. There is no other automate way then to
check each package, since you cant say for sure from the outside, what
sort of build system is used.

> --disable-dependency-tracking problem, or check that every package
> needing revdep-rebuild will be moved to eapi5... 

The most likely solution for this one will be, that whenever someone
gets results from revdep-rebuild (or sees a message from
@preserved-rebuild), he asks the lib maintainer to use the new
dependency type from EAPI-5 to avoid this in the future.


-- 

Thomas Sachau
Gentoo Linux Developer


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

[gentoo-dev] Binary package dependencies for sub-slot-less EAPIs

[W. Trevor King]

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

Over on #gentoo-releng and in gentoo-catalyst@ we've been running into
binary package dependency problems [1].  Before EAPI-5 and sub-slots,
the version of dependency packages is not recorded in the binary
package metadata (the Packages file).  For example, a binary package
for GCC built against mpc-0.8.2 will link to libmpc.so.2.  If you
install that package on a system that only has mpc-1.0.1 (and thus,
libmpc.so.3), your cc1 will crash because libmpc.so.2 is missing.
What we need is a way to track ABI sub-slot dependencies for all
packages, even those that currently use EAPI-0.

My initial idea was to store a fake EAPI-5-style sub-slot information
in the binary package metadata, but further discussion on
#gentoo-portage pointed me at the toolchain folks:

  10:33 < zmedico> dol-sen: wouldn't it be easier to just migrate
          those pkgs to EAPI 5 + slot-operator?
  10:34 * zmedico doesn't feel like doing extra work when EAPI 5
          already does everything we need
  …
  11:16 < Tommy[D]_> Zero_Chaos: my suggestion: ask the toolchain guys
          about their preferred way (like updating existing eclass,
          using a new eclass, moving code into ebuilds) and when you
          got that, do the needed work, including an EAPI-5 version of
          toolchain ebuilds

I looked in bugzilla for requests to update the toolchain EAPIs, but
didn't find anything [2].  I don't want to bother people if the issue
had already been hashed out, and searching on Gmane turned up the
“[RFC] Drop EAPI=0 requirement for system packages.” thread from last
October [3].  This early comment from Rich seemed to summarize the
anti-EAPI-bump camp:

On Wed, Oct 17, 2012 at 03:00:12PM -0400, Rich Freeman wrote:
> A policy that says all new ebuilds shall use EAPI foo might result in
> fewer new ebuilds.  Sure, they'll have new and shiny fooness, but
> arguably I'd rather have more packages supported on older EAPIs then
> fewer packages supported on newer ones.
> 
> Again, as I stated before, things that actually benefit the end users
> like slot dependencies are fine to mandate when it makes sense to do
> so.

In other words, “Why force folks to do this if there is no benefit?”.
This is understandable, but I think the broken binary packages [1] are
enough of a visible benefit.  The thread suggested filing bugs for
bumping effected packages, but for this issue “effected packages” is
“anything you might want to distribute as a binary package that uses
something without EAPI-5 sub-slots” [4].  I'm happy to start filing
bugs, but that doesn't strike me as the most productive way forward.

If anyone can think of other solutions besides tweaking Portage or
bumping a bunch of package EAPIs, I'd be happy to hear them ;).
Otherwise I'd be happy to hear suggestions about moving forward on at
least one of those fronts.  Since I seem to be the most bothered by
this issue, it's only fair that I help with the itch scratching.  I
just need a roadmap from the folks with commit access so I can start
chipping away at whichever solution y'all think looks most appealing
;).

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.linux.gentoo.catalyst/2137/focus=2237
[2]: https://bugs.gentoo.org/buglist.cgi?short_desc=EAPI&resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&short_desc_type=allwordssubstr&component=Core%20system&component=Development&component=Core%20system&component=Development&product=Gentoo%20Linux
[3]: http://thread.gmane.org/gmane.linux.gentoo.devel/80705
[4]: Although on the catalyst side, only @system is really important.



-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

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

Re: [gentoo-dev] Binary package dependencies for sub-slot-less EAPIs

[Rich Freeman]

On Fri, Apr 12, 2013 at 12:25 PM, W. Trevor King <wking@tremily.us> wrote:
> In other words, “Why force folks to do this if there is no benefit?”.
> This is understandable, but I think the broken binary packages [1] are
> enough of a visible benefit.

I certainly agree.  As I bump my own packages I'll certainly be
looking for opportunities to use slot operator dependencies and will
certainly bump to EAPI5 when I find them, and if somebody were to
state that EAPI6 was going to make the lives of binary package users
much better I'd be all for pushing to get everything onto EAPI6.

My only concern was to let the actual benefits be the driver.

Rich