[gentoo-dev] [RFC] Tightening EAPI rules

[gentoo-dev] [RFC] Tightening EAPI rules

[Patrick Lauer]

As previously discussed I would like to suggest that the number of
tolerated EAPIs be reduced. There's been some discussion
over the last 2+ years, with a weak consensus towards deprecating
some EAPIs. What, when and how still isn't decided.
So let's add some data so we have a better idea:

EAPI Statistics:

The daily updated stats [2] show a slow general trend down.
There's historical data (well, just a few days right now at [3]

The current sum of all ebuilds in tree adds up to ~10% EAPI 1+2
EAPI0 is still surprisingly big around ~15%
EAPI3 is about as big as EAPI2 at around ~7%

According to [1] EAPI 1 and 2 are deprecated.
At the time EAPI 0 was in limbo as toolchain required it
(What's the current status of toolchain on that?)

I suggest the following change:

[ EAPI 0 depends on toolchain's acceptance.
Should toolchain agree then adding EAPI0 ebuilds becomes forbidden]
Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
EAPI 3 becomes deprecated (like 1 and 2 are now)
Adding EAPI 3 ebuilds is forbidden in now +3 months

EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree
(EAPI 6, most likely)

EAPI 5 is the recommended default.


Rationale:
More than two supported EAPIs is an unneeded burden on developers.
Thus 4 will be deprecated when post-5 becomes added.

There's no immediate need to forbid the antepenultimate EAPI immediately.

The goal of this upgrade policy is that we can accelerate the expiration
of old EAPIs - EAPI 2 happened
at some point in 2008, I think (or 2009?) and we still carry
five-year-old cruft around.

Given the percentages -

EAPI 1 can be "cleaned out" by a single motivated individual. It's
almost gone.

EAPI 2 and 3 will take a few months at least, even if there's a
coordinated effort to migrate.
EAPI 0 is as big as 2 and 3 together, and depends on toolchain herd's
actions.
It'll still be around for a looong time. (Given the current rate of
change, plus repoman support, plus people actively working on pruning
it, I would assume it'll take at least a year, more likely two)

In other words, even if we go for the "fastest" option you won't see any
revolutionary change :)

Please no bikeshedding,

Patrick


[1] https://www.gentoo.org/proj/en/council/meeting-logs/20130409.txt
[2] http://packages.gentooexperimental.org/eapi-stats.txt
[3] http://packages.gentooexperimental.org/eapi-history/

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Dirkjan Ochtman]

On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> The daily updated stats [2] show a slow general trend down.
> There's historical data (well, just a few days right now at [3]

What are you looking at here? .ebuild files in the tree? Or latest
version per-package?

Old EAPI versions are obviously only a burden for developers if there
are actually developers looking at those packages/versions/ebuilds...

Cheers,

Dirkjan

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 14:03:49 +0100
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Feb 10, 2014 at 1:43 PM, Patrick Lauer <patrick@gentoo.org>
> wrote:
> > The daily updated stats [2] show a slow general trend down.
> > There's historical data (well, just a few days right now at [3]
> 
> What are you looking at here? .ebuild files in the tree? Or latest
> version per-package?

The same as the repoman warnings do, the .ebuild files; to confirm this
`grep -r --include='*.ebuild'
'^\w*EAPI=\(['"'"'"]1['"'"'"]\|1\)' /usr/portage/ | wc -l` yields 361.

> Old EAPI versions are obviously only a burden for developers if there
> are actually developers looking at those packages/versions/ebuilds...

Maintainership over a package would imply that you also maintain all of
its versions, unless you restrict yourself (but then the rest goes m-n);
they don't necessarily sit in the way for a maintainer, however, there's
still the possibility for people to use them as well as that they cause
bugs that stay around and act as noise. But there's something else:

Apart from that, they however sit in the way of deprecating support for
that EAPI; at one point it becomes tedious to have to support 10 EAPIs
in our code (eg. Portage), hence we should aim to deprecate versions of
a few years old. Keeping old stuff around can take its toll...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Dirkjan Ochtman]

On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> Apart from that, they however sit in the way of deprecating support for
> that EAPI; at one point it becomes tedious to have to support 10 EAPIs
> in our code (eg. Portage), hence we should aim to deprecate versions of
> a few years old. Keeping old stuff around can take its toll...

Sure, but Patrick was explicitly talking about a burden on developers,
not a burden on package manager implementers.

Cheers,

Dirkjan

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 14:24:39 +0100
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Feb 10, 2014 at 2:21 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > Apart from that, they however sit in the way of deprecating support
> > for that EAPI; at one point it becomes tedious to have to support
> > 10 EAPIs in our code (eg. Portage), hence we should aim to
> > deprecate versions of a few years old. Keeping old stuff around can
> > take its toll...
> 
> Sure, but Patrick was explicitly talking about a burden on developers,
> not a burden on package manager implementers.

Well, that package maintainers are called developers on Gentoo isn't
helping the interpretation here; regardless of how one defines those,
both maintainers and PM implementers have to be taken into account here.

From quick thoughts the latter are a bit more affected than the former,
but perhaps Patrick can highlight what he sees as a burden.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> Well, that package maintainers are called developers on Gentoo isn't
> helping the interpretation here; regardless of how one defines those,
> both maintainers and PM implementers have to be taken into account here.
>
> From quick thoughts the latter are a bit more affected than the former,
> but perhaps Patrick can highlight what he sees as a burden.

You would think, but the reason I raised the question was that
historically every time this has come up the package manager
maintainers usually chime in and say that they don't consider it a
problem.  I want to do whatever I can to make them happy since we are
so desperately in need of more of them, but...

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 09:41:13 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > Well, that package maintainers are called developers on Gentoo isn't
> > helping the interpretation here; regardless of how one defines
> > those, both maintainers and PM implementers have to be taken into
> > account here.
> >
> > From quick thoughts the latter are a bit more affected than the
> > former, but perhaps Patrick can highlight what he sees as a burden.
> 
> You would think, but the reason I raised the question was that
> historically every time this has come up the package manager
> maintainers usually chime in and say that they don't consider it a
> problem.  I want to do whatever I can to make them happy since we are
> so desperately in need of more of them, but...

From my limited look at the code I've done so far in the small bit of
repoman work on the Portage team, as detailed in another mail I just
sent to you on this ML, I wouldn't consider it as a problem just now.

We for example have /usr/lib/portage/pym/portage/eapi.py to easily deal
with it, it's just that such checks would drop in that file and across
the Portage source code when the versions listed in those checks are no
longer used. It's currently reasonable to have this amount of checks,
but imagine it growing to what you would need for 10 versions; that'd be
a different story, but perhaps it is too early to wonder about this now.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ciaran McCreesh]

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

On Mon, 10 Feb 2014 15:58:23 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:
> On Mon, 10 Feb 2014 09:41:13 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
> > On Mon, Feb 10, 2014 at 9:23 AM, Tom Wijsman <TomWij@gentoo.org>
> > wrote:
> > > Well, that package maintainers are called developers on Gentoo
> > > isn't helping the interpretation here; regardless of how one
> > > defines those, both maintainers and PM implementers have to be
> > > taken into account here.
> > >
> > > From quick thoughts the latter are a bit more affected than the
> > > former, but perhaps Patrick can highlight what he sees as a
> > > burden.
> > 
> > You would think, but the reason I raised the question was that
> > historically every time this has come up the package manager
> > maintainers usually chime in and say that they don't consider it a
> > problem.  I want to do whatever I can to make them happy since we
> > are so desperately in need of more of them, but...
> 
> From my limited look at the code I've done so far in the small bit of
> repoman work on the Portage team, as detailed in another mail I just
> sent to you on this ML, I wouldn't consider it as a problem just now.
> 
> We for example have /usr/lib/portage/pym/portage/eapi.py to easily
> deal with it, it's just that such checks would drop in that file and
> across the Portage source code when the versions listed in those
> checks are no longer used. It's currently reasonable to have this
> amount of checks, but imagine it growing to what you would need for
> 10 versions; that'd be a different story, but perhaps it is too early
> to wonder about this now.

Removing EAPIs doesn't help you: you still need to be able to uninstall
things.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

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

On Mon, 10 Feb 2014 16:16:42 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> > From my limited look at the code I've done so far in the small bit
> > of repoman work on the Portage team, as detailed in another mail I
> > just sent to you on this ML, I wouldn't consider it as a problem
> > just now.
> > 
> > We for example have /usr/lib/portage/pym/portage/eapi.py to easily
> > deal with it, it's just that such checks would drop in that file and
> > across the Portage source code when the versions listed in those
> > checks are no longer used. It's currently reasonable to have this
> > amount of checks, but imagine it growing to what you would need for
> > 10 versions; that'd be a different story, but perhaps it is too
> > early to wonder about this now.
> 
> Removing EAPIs doesn't help you: you still need to be able to
> uninstall things.

There aren't much checks left if you only need to cover that.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Anthony G. Basile]

On 02/10/2014 07:43 AM, Patrick Lauer wrote:
> EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree
> (EAPI 6, most likely)

I am concerned about making this a "rule".  While I think its okay for 
the 4/5/6 move, I'm not sure if it will always be a good idea. 1) 
"Deprecating" an EAPI can mean breakage --- see my next point. 2) To tie 
the deprecation of the older EAPI to the introduction of a newer one can 
delay the introduction of the newer one and possibly needed features.  
You will connect the question of "are we ready to deprecate X" with the 
question "we need to introduce Y for needed features a, b and c."

The statement "Deprecating an EAPI can mean breakage" depends on what we 
mean by "deprecating."  I'm assuming here we mean something like repoman 
won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those 
EAPI's will continue working.  Eg. dosed which was deprecated in the 
EAPI 3 to 4 jump.

I think we should look at the question of deprecating EAPI's on and ad 
hoc basis with discussion on the list and a vote in the council.

--Tony

>
>
> Please no bikeshedding,

It should be red.

>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Patrick Lauer]

On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
> The statement "Deprecating an EAPI can mean breakage" depends on what we
> mean by "deprecating."  I'm assuming here we mean something like repoman
> won't allow commits at EAPI=1,2,3 but that ebuilds in the tree at those
> EAPI's will continue working.  Eg. dosed which was deprecated in the
> EAPI 3 to 4 jump.

Right now EAPI 1 and 2 are deprecated, which means repoman prints some
warnings that get ignored and nothing happens.

Going from the current state I would distinguish between deprecated
(=unwanted, but tolerated) and banned (not tolerated)

> 
> I think we should look at the question of deprecating EAPI's on and ad
> hoc basis with discussion on the list and a vote in the council.

I think it's safe to deprecate the antepenultimate EAPI, and then do the
banning on a more delayed and controlled basis.

Patrick

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 8:46 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> I think it's safe to deprecate the antepenultimate EAPI, and then do the
> banning on a more delayed and controlled basis.

Yeah, I don't think we need to overly debate deprecation, other than
in corner cases like the toolchain (just that minor thing...).

I guess to turn things around, does anybody strongly object to the
council banning an EAPI or two?

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ian Stakenvicius]

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

On 10/02/14 08:46 AM, Patrick Lauer wrote:
> On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
>> The statement "Deprecating an EAPI can mean breakage" depends on
>> what we mean by "deprecating."  I'm assuming here we mean
>> something like repoman won't allow commits at EAPI=1,2,3 but that
>> ebuilds in the tree at those EAPI's will continue working.  Eg.
>> dosed which was deprecated in the EAPI 3 to 4 jump.
> 
> Right now EAPI 1 and 2 are deprecated, which means repoman prints
> some warnings that get ignored and nothing happens.

Back when these were deprecated, the general consensus was that we
shouldn't change (especially stable) ebuilds in the tree and just
upgrade when we revbump or version bump.

Is this still true?  If so, I'm wondering how many of those older-EAPI
ebuilds are just plain old...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlL44T8ACgkQ2ugaI38ACPCl1gEAqQYhWVUPjZu05NNAhkhuy36o
jlWfu0lJc6irf5Q2vhkA/0NGS29ceLdGjqLbTa8fYPNlQ/4sntpC04tIMuPI4Obm
=xnk2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ulrich Mueller]

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

>>>>> On Mon, 10 Feb 2014, Patrick Lauer wrote:

> On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
>> I think we should look at the question of deprecating EAPI's on and
>> ad hoc basis with discussion on the list and a vote in the council.

+1

> I think it's safe to deprecate the antepenultimate EAPI, and then do
> the banning on a more delayed and controlled basis.

I'd rather argue in terms of time instead of version numbers, because
of the upgrade path for old systems. We guarantee one year for stable
systems, but IMHO we should be more conservative for EAPI deprecation
and go for two or three years there.

Anyway, the Portage version supporting EAPI 4 became stable on
2011-03-17 [1], so it looks like EAPI 3 could be deprecated soon.

Ulrich

[1] https://wiki.gentoo.org/wiki/Project:PMS#EAPI_life_cycle

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

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> I'd rather argue in terms of time instead of version numbers, because
> of the upgrade path for old systems. We guarantee one year for stable
> systems, but IMHO we should be more conservative for EAPI deprecation
> and go for two or three years there.

By EAPI deprecation it is meant that we discourage using the old EAPI
in the tree.  Removing support for it from a package manager should of
course happen much later (well after it is banned).

There is always the upgrade path problem when system packages start
using the new EAPI and eventually the dependencies to do a portage
upgrade can't be installed using an old version of portage.  However,
that problem exists regardless of EAPI deprecation - it is more about
when we migrate system packages or whether we save tree/distfile
snapshots and so on.  Even if we don't deprecate the old EAPIs if
@system maintainers start bumping their packages there will eventually
be problems for users who don't update soon.

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Ulrich Mueller]

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

>>>>> On Mon, 10 Feb 2014, Rich Freeman wrote:

> On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
>> I'd rather argue in terms of time instead of version numbers,
>> because of the upgrade path for old systems. We guarantee one year
>> for stable systems, but IMHO we should be more conservative for
>> EAPI deprecation and go for two or three years there.

> By EAPI deprecation it is meant that we discourage using the old
> EAPI in the tree.

Right, the above was about ebuilds in the tree, not about package
managers. At least sys-apps/portage and its dependencies must stay at
an EAPI that is stable long enough to allow an upgrade of old systems
(where Portage might not recognise the newest EAPI).

> Removing support for it from a package manager should of course
> happen much later (well after it is banned).

The package manager must be able to uninstall old packages, which
essentially means that support for old EAPIs cannot be removed.

Ulrich

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

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Alan McKinnon]

On 10/02/2014 18:05, Ulrich Mueller wrote:
>> Removing support for it from a package manager should of course
>> > happen much later (well after it is banned).
> The package manager must be able to uninstall old packages, which
> essentially means that support for old EAPIs cannot be removed.


I feel this aspect needs to be limited, no user can reasonably expect
Gentoo devs to retain support in the package manager for obsolete
features indefinitely. We also shouldn't be too hasty in removing the
support, but there has to be a cut-off point somewhere, a point of no
return. It's probably measured in years, my thumb suck guess is 3 years
after a given EAPI is finally obsoleted.

As a real example - I know someone who proudly shows off a Gentoo host
with a 2004 profile. Can he reasonably expect portage to still work
flawlessly 10 years later? I feel no, luckily he agrees with me.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Alec Warner]

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

On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon <alan.mckinnon@gmail.com>wrote:

> On 10/02/2014 18:05, Ulrich Mueller wrote:
> >> Removing support for it from a package manager should of course
> >> > happen much later (well after it is banned).
> > The package manager must be able to uninstall old packages, which
> > essentially means that support for old EAPIs cannot be removed.
>
>
> I feel this aspect needs to be limited, no user can reasonably expect
> Gentoo devs to retain support in the package manager for obsolete
> features indefinitely. We also shouldn't be too hasty in removing the
> support, but there has to be a cut-off point somewhere, a point of no
> return. It's probably measured in years, my thumb suck guess is 3 years
> after a given EAPI is finally obsoleted.
>

Why is that unreasonable?

-A



>
> As a real example - I know someone who proudly shows off a Gentoo host
> with a 2004 profile. Can he reasonably expect portage to still work
> flawlessly 10 years later? I feel no, luckily he agrees with me.
>
> --
> Alan McKinnon
> alan.mckinnon@gmail.com
>
>
>

[-- Attachment #2: Type: text/html, Size: 1805 bytes --]

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Alan McKinnon]

On 10/02/2014 22:56, Alec Warner wrote:
> On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon <alan.mckinnon@gmail.com
> <mailto:alan.mckinnon@gmail.com>> wrote:
> 
>     On 10/02/2014 18:05, Ulrich Mueller wrote:
>     >> Removing support for it from a package manager should of course
>     >> > happen much later (well after it is banned).
>     > The package manager must be able to uninstall old packages, which
>     > essentially means that support for old EAPIs cannot be removed.
> 
> 
>     I feel this aspect needs to be limited, no user can reasonably expect
>     Gentoo devs to retain support in the package manager for obsolete
>     features indefinitely. We also shouldn't be too hasty in removing the
>     support, but there has to be a cut-off point somewhere, a point of no
>     return. It's probably measured in years, my thumb suck guess is 3 years
>     after a given EAPI is finally obsoleted.
> 
> 
> Why is that unreasonable?

It's unreasonable for me to expect you to support long-dead features and
EAPIs. Unless you choose to support them of course, or if it's no big
deal to support them (I have a hunch this last is not true, that it is a
big deal actually).

The bottom line is that I don't pay you to write the pm I use, so I have
no expectation that stuff will always work forever. A host where portage
has not been updated for 2 years is basically a moribund host



> 
> -A
> 
>  
> 
> 
>     As a real example - I know someone who proudly shows off a Gentoo host
>     with a 2004 profile. Can he reasonably expect portage to still work
>     flawlessly 10 years later? I feel no, luckily he agrees with me.
> 
>     --
>     Alan McKinnon
>     alan.mckinnon@gmail.com <mailto:alan.mckinnon@gmail.com>
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

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

On Mon, 10 Feb 2014 17:05:22 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Mon, 10 Feb 2014, Rich Freeman wrote:
> 
> > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller <ulm@gentoo.org>
> > wrote:
> >> I'd rather argue in terms of time instead of version numbers,
> >> because of the upgrade path for old systems. We guarantee one year
> >> for stable systems, but IMHO we should be more conservative for
> >> EAPI deprecation and go for two or three years there.
> 
> > By EAPI deprecation it is meant that we discourage using the old
> > EAPI in the tree.
> 
> Right, the above was about ebuilds in the tree, not about package
> managers. At least sys-apps/portage and its dependencies must stay at
> an EAPI that is stable long enough to allow an upgrade of old systems
> (where Portage might not recognise the newest EAPI).

Yes, besides the way we deprecate it we should also be clear in our
wording what this all pertains to; a broad statement can has its effect
in the Portage tree, the package manager, the upgrade path, the vdb and
possibly more. Otherwise we get what Patrick describes; a warning in
repoman, with nearly no progress wrt its removal in the Portage tree.

> > Removing support for it from a package manager should of course
> > happen much later (well after it is banned).
> 
> The package manager must be able to uninstall old packages, which
> essentially means that support for old EAPIs cannot be removed.

That's only a subset of the entire EAPI, which could be separately
still supported; while no longer supporting the majority of it, for
example, whether src_prepare is supported doesn't really matter anymore
when you are uninstalling a package. One could make up a list; however,
it's not a problem yet, it might become one in 10 years or so...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 12:20 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Mon, 10 Feb 2014 17:05:22 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> The package manager must be able to uninstall old packages, which
>> essentially means that support for old EAPIs cannot be removed.
>
> That's only a subset of the entire EAPI, which could be separately
> still supported; while no longer supporting the majority of it, for
> example, whether src_prepare is supported doesn't really matter anymore
> when you are uninstalling a package. One could make up a list; however,
> it's not a problem yet, it might become one in 10 years or so...

Well, that strikes me as a cross-that-bridge-when-we-get-to-it
problem.  However, if maintaining the code becomes a problem we could
always create a script that finds and re-installs any package that
uses an about-to-be-desupported EAPI and then the system will be clean
of them.  It doesn't sound nearly as bad as that glibc upgrade that
broke the ABI a decade ago, and it would only impact packages that
hadn't been otherwise updated in a long time...

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Lars Wendler]

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

On Mon, 10 Feb 2014 21:46:56 +0800 Patrick Lauer wrote:

>On 02/10/2014 09:23 PM, Anthony G. Basile wrote:
>> The statement "Deprecating an EAPI can mean breakage" depends on
>> what we mean by "deprecating."  I'm assuming here we mean something
>> like repoman won't allow commits at EAPI=1,2,3 but that ebuilds in
>> the tree at those EAPI's will continue working.  Eg. dosed which was
>> deprecated in the EAPI 3 to 4 jump.
>
>Right now EAPI 1 and 2 are deprecated, which means repoman prints some
>warnings that get ignored and nothing happens.

Not in my case. I EAPI-bump each ebuild to either EAPI-4
(base-system packages) or EAPI-5 where repoman complains about when I
put my fingers on them...
I hope I am not the only one doing this.

>Going from the current state I would distinguish between deprecated
>(=unwanted, but tolerated) and banned (not tolerated)
>
>> 
>> I think we should look at the question of deprecating EAPI's on and
>> ad hoc basis with discussion on the list and a vote in the council.
>
>I think it's safe to deprecate the antepenultimate EAPI, and then do
>the banning on a more delayed and controlled basis.
>
>Patrick
>
>

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

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

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 08:23:51 -0500
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 02/10/2014 07:43 AM, Patrick Lauer wrote:
> > EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree
> > (EAPI 6, most likely)
> 
> I am concerned about making this a "rule".

Maybe rather a rule with exceptions, or a rather strong recommendation;
as we've seen easier, sometimes a rule needs a revision.

> While I think its okay for the 4/5/6 move, I'm not sure if it will
> always be a good idea. 1) "Deprecating" an EAPI can mean breakage ---
> see my next point. 2) To tie the deprecation of the older EAPI to the
> introduction of a newer one can delay the introduction of the newer
> one and possibly needed features. You will connect the question of
> "are we ready to deprecate X" with the question "we need to introduce
> Y for needed features a, b and c."

It is hard to grasp for me for when features from a newer EAPI would
delay the migration, do you have an example?

> The statement "Deprecating an EAPI can mean breakage" depends on what
> we mean by "deprecating."  I'm assuming here we mean something like
> repoman won't allow commits at EAPI=1,2,3 but that ebuilds in the
> tree at those EAPI's will continue working.  Eg. dosed which was
> deprecated in the EAPI 3 to 4 jump.

Good point, we should probably split this up in multiple phases:

 1) Repoman warns about deprecation of ebuilds with older EAPI.

 2) Repoman bails out on the addition of _new_ ebuilds with older EAPI.

 3) Repoman bails out on changes to _existing_ ebuilds with older EAPI.

As a side note, we'll need to implement VCS diff support in repoman to
check for this; as currently you can only check based the ebuilds.
Nevertheless a hack is possible, but I think we should avoid that...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Anthony G. Basile]

On 02/10/2014 09:35 AM, Tom Wijsman wrote:
>> one and possibly needed features. You will connect the question of
>> >"are we ready to deprecate X" with the question "we need to introduce
>> >Y for needed features a, b and c."
> It is hard to grasp for me for when features from a newer EAPI would
> delay the migration, do you have an example?
>

That's not what i mean.  It is possible that we may want the newer EAPI 
for the features it brings but be as yet unwilling to deprecated the 
older EAPI for stability reasons.  Even if the newer EAPI is a proper 
superset of the older, hidden implementation changes have not been 
tested well and we might want to be more caution about deprecating our 
older yet very stable EAPI.  EAPI=4 is very stable right now.  I have 
more confidence in it that 5 simply because of the coverage and testing 
its gotten.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Rich Freeman]

On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)

Does "adding" in this case include revbumps?

> More than two supported EAPIs is an unneeded burden on developers.

Is this really a generally held belief?  I don't find it a burden that
ebuilds in the tree may use various EAPIs.  I could see how they make
scripted mass-updates to ebuilds more difficult, though I'm not sure
how much of an issue this is in practice.

I could also see how supporting many EAPIs could be a burden on
package managers, but if that is a concern I'd be interested in
hearing from these maintainers.

My sense is that deprecating probably makes sense, but banning should
only be done if in reaction to a particular problem.  Repoman warnings
call attention to the issue so that the maintainer is aware and can
take the appropriate action, but without restricting their actions.

Now, if people are actually impacted by all the EAPIs I don't mind
pushing harder to get rid of some.

Rich

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Patrick Lauer]

On 02/10/2014 09:34 PM, Rich Freeman wrote:
> On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
> 
> Does "adding" in this case include revbumps?

By the design of our repo structure and repoman, yes.

(I don't see a clean way around that)

>> More than two supported EAPIs is an unneeded burden on developers.
> 
> Is this really a generally held belief? 
Not a belief but experience - I find it really hard to remember all the
corner cases with 6 different flavours (plus eclasses in multiple
revisions, etc. etc.)

Most stuff is "similar enough" to cause funny bugs (like src_prepare not
working, sigh :D )

For me it makes sense to homogenize things so accidental mistakes become
more rare.

Patrick

Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 08:34:00 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer <patrick@gentoo.org>
> wrote:
> > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
> 
> Does "adding" in this case include revbumps?

Yes; though, we kind of expect rev bumps to include multiple fixes if
possible, not just a fix for a particular bug. It is indeed kind of up
to the maintainer if he wants to include trivial fixes like EAPI bumps
and what not; though, it can be really fun when you add patches to
src_prepare in an EAPI that doesn't support src_prepare yet... :)

> > More than two supported EAPIs is an unneeded burden on developers.
> 
> Is this really a generally held belief?  I don't find it a burden that
> ebuilds in the tree may use various EAPIs.  I could see how they make
> scripted mass-updates to ebuilds more difficult, though I'm not sure
> how much of an issue this is in practice.
> 
> I could also see how supporting many EAPIs could be a burden on
> package managers, but if that is a concern I'd be interested in
> hearing from these maintainers.
> 
> My sense is that deprecating probably makes sense, but banning should
> only be done if in reaction to a particular problem.  Repoman warnings
> call attention to the issue so that the maintainer is aware and can
> take the appropriate action, but without restricting their actions.
> 
> Now, if people are actually impacted by all the EAPIs I don't mind
> pushing harder to get rid of some.

A lot of this is more of a future proof approach than to address an
actual practical problem; the ~5 or so cases we've got to support in
PMs, which are actually often just ~2 or ~3, aren't really a burden as
it stands now. But once that gets to the ~10 cases, which boils down to
often like maybe ~4 to ~6 cases; it becomes a bit more bloated up to a
point you really start yelling at code cruft, but we're still far from
as there are less often PMS releases these days.

Well, some of us also see it as code cruft in the Portage tree; also in
a way that is growing as we get more releases of the PMS, this will
probably not ever really bother maintainers (unless we expect them to
know how older EAPIs were by heart, this is comparable to how web
developers need to account for older versions of browsers) but it really
could start to bother those whom look over the whole Portage tree.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[gentoo-dev] Re: [RFC] Tightening EAPI rules

[Ryan Hill]

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

On Mon, 10 Feb 2014 20:43:41 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> At the time EAPI 0 was in limbo as toolchain required it
> (What's the current status of toolchain on that?)

GCC is now EAPI 2 except for gcc-apple and kgcc64.  I'm going to deprecate EAPI
0 and 1 soon but need to give people time to update overlays afterwards.  It
won't be hard to move to 4 after that but it'll need another deprecation cycle.

You'll have to ask Mike about glibc and binutils.

Personally I think we should always keep the latest three EAPIs around, so 4, 5,
and 6 (and 0).


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

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