[gentoo-dev] RFC: Deprecating EAPI0

[gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

Hi all,

with the discussion about EAPI3 we have now 4 (or 7, depending on how you 
count them ;) ) EAPIs available or almost available. This is getting quite 
confusing.
To make our lives easier I would suggest deprecating EAPI0 and migrating 
existing ebuilds over some time to EAPI1 or higher until EAPI0 can be 
obsoleted at some point in the future.
I would set the start of deprecation warnings about 3 months from now and the 
obsoletion quite a time later, maybe 12 months from now, when a sufficient 
amount of ebuilds has been migrated.

Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to 
think about, but since it has some changes like adding src_prepare migration 
would not be as trivial. So I'd prefer keeping it around a bit longer.

Comments?


Patrick 

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Alec Warner]

On Sat, Mar 21, 2009 at 10:37 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Hi all,
>
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> count them ;) ) EAPIs available or almost available. This is getting quite
> confusing.

Be more specific, what actual problems have you encountered?
What are some other ways we could mitigate these issues (it seems like
tool improvements could be a big one here)?

> To make our lives easier I would suggest deprecating EAPI0 and migrating
> existing ebuilds over some time to EAPI1 or higher until EAPI0 can be
> obsoleted at some point in the future.
> I would set the start of deprecation warnings about 3 months from now and the
> obsoletion quite a time later, maybe 12 months from now, when a sufficient
> amount of ebuilds has been migrated.

I am interested in the number of ebuilds at specific APIs in the tree,
do you have those numbers?
Basically, how much work is this (raw ebuild count)?

>
> Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to
> think about, but since it has some changes like adding src_prepare migration
> would not be as trivial. So I'd prefer keeping it around a bit longer.
>
> Comments?
>
>
> Patrick
>
>

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Daniel Pielmeier]

Alec Warner schrieb am 21.03.2009 20:45:
> 
> Be more specific, what actual problems have you encountered?
> What are some other ways we could mitigate these issues (it seems like
> tool improvements could be a big one here)?
> 

Regarding the depreciation of EAPI's I think eclasses will probably 
benefit from a low number of possible EAPI's. I am thinking about the 
introduction of more and more EAPI's which all need to be considered in 
the eclasses which will get tedious.

Regards,

Daniel

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Sat, 21 Mar 2009 18:37:12 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> To make our lives easier I would suggest deprecating EAPI0 and
> migrating existing ebuilds over some time to EAPI1 or higher until
> EAPI0 can be obsoleted at some point in the future.

Uh. Why?

Introducing a policy encouraging moving things that definitely aren't
in the least bit likely to be a system dep on a bump, sure. Making 1 or
2 the default for new packages, sure. But rewriting existing things?
That's just an accident waiting to happen.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Markos Chandras]

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

On Saturday 21 March 2009 19:37:12 Patrick Lauer wrote:
> Hi all,
>
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> count them ;) ) EAPIs available or almost available. This is getting quite
> confusing.
> To make our lives easier I would suggest deprecating EAPI0 and migrating
> existing ebuilds over some time to EAPI1 or higher until EAPI0 can be
> obsoleted at some point in the future.
> I would set the start of deprecation warnings about 3 months from now and
> the obsoletion quite a time later, maybe 12 months from now, when a
> sufficient amount of ebuilds has been migrated.
>
> Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have
> to think about, but since it has some changes like adding src_prepare
> migration would not be as trivial. So I'd prefer keeping it around a bit
> longer.
>
> Comments?
>
>
> Patrick
	The gain obtained by this migration doesnt compensate for the efford/work one 
(we) must put into this. But if we decide to mark EAPI0 as deprecated, first it 
would be nice to have a tree cleanup cause it doesn't make much sense to 
migrate broken/unmaintained/old/etc ebuilds onto newer EAPIs.

--
Markos Chandras (hwoarang)
Gentoo Linux Developer
KDE/Qt/Sunrise/Sound
Web: http://hwoarang.silverarrow.gr

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Alexey Shvetsov]

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

Alec Warner wrote:
> I am interested in the number of ebuilds at specific APIs in the tree,
> do you have those numbers?
> Basically, how much work is this (raw ebuild count)?
>
Total ebuilds	26209
EAPI0 ebuilds	22880
EAPI1 ebuilds	1855
EAPI2 ebuilds	1474

this numbers based on regexps =)

-- 
Alexey 'Alexxy' Shvetsov
Gentoo/KDE
Gentoo/MIPS
Gentoo/SCI
Gentoo Team Ru

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 18:37:12 +0100
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > To make our lives easier I would suggest deprecating EAPI0 and
> > migrating existing ebuilds over some time to EAPI1 or higher until
> > EAPI0 can be obsoleted at some point in the future.
>
> Uh. Why?
Because, as you have noticed before, developers get confused which eapi has 
which features available. And eapi1 is a superset of eapi0, so we don't have 
to rewrite tons of things. 

> Introducing a policy encouraging moving things that definitely aren't
> in the least bit likely to be a system dep on a bump, sure. Making 1 or
> 2 the default for new packages, sure. But rewriting existing things?
> That's just an accident waiting to happen.
What kind of accident do you expect to happen?

Patrick

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Sat, 21 Mar 2009 21:53:16 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> Because, as you have noticed before, developers get confused which
> eapi has which features available. And eapi1 is a superset of eapi0,
> so we don't have to rewrite tons of things. 

So? When people do new things, they can move the EAPI forward. That's
not a reason to modify existing things.

> > Introducing a policy encouraging moving things that definitely
> > aren't in the least bit likely to be a system dep on a bump, sure.
> > Making 1 or 2 the default for new packages, sure. But rewriting
> > existing things? That's just an accident waiting to happen.
>
> What kind of accident do you expect to happen?

The same kind that always happens when lots of ebuilds get changed.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Jeremy Olexa]

Alexey Shvetsov wrote:
> Alec Warner wrote:
>> I am interested in the number of ebuilds at specific APIs in the tree,
>> do you have those numbers?
>> Basically, how much work is this (raw ebuild count)?
>>
> Total ebuilds	26209
> EAPI0 ebuilds	22880
> EAPI1 ebuilds	1855
> EAPI2 ebuilds	1474
> 
> this numbers based on regexps =)
> 

With these numbers, I don't exactly see the point of deprecating EAPI0. 
Too much work that we could be spending elsewhere.. Although, I suppose 
someone will propose to make the "default EAPI" be 1 instead of 0. I 
don't see a point for that either.

-Jeremy

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 21:53:16 +0100
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > Because, as you have noticed before, developers get confused which
> > eapi has which features available. And eapi1 is a superset of eapi0,
> > so we don't have to rewrite tons of things.
>
> So? When people do new things, they can move the EAPI forward. That's
> not a reason to modify existing things.

The added complexity of having a dozen eapis does not offer any benefits to 
the average developer. Limiting the amount of complexity tends to reduce the 
amount of errors, be it simple developer mistakes or unexpected interaction 
errors between different EAPIs in the package manager.

> > > Introducing a policy encouraging moving things that definitely
> > > aren't in the least bit likely to be a system dep on a bump, sure.
> > > Making 1 or 2 the default for new packages, sure. But rewriting
> > > existing things? That's just an accident waiting to happen.
> >
> > What kind of accident do you expect to happen?
>
> The same kind that always happens when lots of ebuilds get changed.

... lots of new features and a few bugs that get fixed the next day? Hey, that 
sounds quite bad. And maybe some new herd testers? How rude!

So what technical reason(s) do we have to keep archaic EAPIs around forever?

Patrick

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Sat, 21 Mar 2009 22:02:54 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> > So? When people do new things, they can move the EAPI forward.
> > That's not a reason to modify existing things.
> 
> The added complexity of having a dozen eapis does not offer any
> benefits to the average developer.

There is no added complexity. Those things are already there.

> > The same kind that always happens when lots of ebuilds get changed.
> 
> ... lots of new features and a few bugs that get fixed the next day?

You must be new around here.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Alec Warner]

On Sat, Mar 21, 2009 at 2:02 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote:
>> On Sat, 21 Mar 2009 21:53:16 +0100
>>
>> Patrick Lauer <patrick@gentoo.org> wrote:
>> > Because, as you have noticed before, developers get confused which
>> > eapi has which features available. And eapi1 is a superset of eapi0,
>> > so we don't have to rewrite tons of things.
>>
>> So? When people do new things, they can move the EAPI forward. That's
>> not a reason to modify existing things.
>
> The added complexity of having a dozen eapis does not offer any benefits to
> the average developer. Limiting the amount of complexity tends to reduce the
> amount of errors, be it simple developer mistakes or unexpected interaction
> errors between different EAPIs in the package manager.

But you are still talking around the issue.  Your logic is that "lots
of EAPIs mean its harder to write ebuilds."
I buy that argument (complexity implies difficult, no problem!) but it
is a very generic argument.  What about the complexity of many EAPIs
are developers having issues with?  What can we do to mitigate these problems?

Are people using IUSE_DEFAULTS in EAPI0?  Are they not bumping the
EAPI when adding src_configure to an ebuild?  You claim there are all
kinds of problems, I want to hear about them so we can fix the tools
(aka repoman) to help point out where developers go wrong so they can
fix them.

Over 80% of the tree is still EAPI0, so deprecating it seems a bad
choice at this time, even for a 12-16 month timeline.

>
>> > > Introducing a policy encouraging moving things that definitely
>> > > aren't in the least bit likely to be a system dep on a bump, sure.
>> > > Making 1 or 2 the default for new packages, sure. But rewriting
>> > > existing things? That's just an accident waiting to happen.
>> >
>> > What kind of accident do you expect to happen?
>>
>> The same kind that always happens when lots of ebuilds get changed.
>
> ... lots of new features and a few bugs that get fixed the next day? Hey, that
> sounds quite bad. And maybe some new herd testers? How rude!

I don't see the correlation between EAPI bumps and new herd testers.

>
> So what technical reason(s) do we have to keep archaic EAPIs around forever?

None, luckily this is more than a technical project ;)

>
> Patrick
>
>

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Peter Alfredsen]

On Sat, 21 Mar 2009 18:37:12 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> To make our lives easier I would suggest deprecating EAPI0 and
> migrating existing ebuilds over some time to EAPI1 or higher until
> EAPI0 can be obsoleted at some point in the future.
> I would set the start of deprecation warnings about 3 months from now
> and the obsoletion quite a time later, maybe 12 months from now, when
> a sufficient amount of ebuilds has been migrated.

As always, wording is important. I think having too many EAPIs in
active use unnecessarily complicates things, such as remembering which
features are offered by which EAPIs, etc. I think we should start
deprecating EAPI=0 usage *now* with a repoman warning whenever a new
ebuild is committed that does not use EAPI=1 or EAPI=2. This warning
should encourage use of the newest EAPI, EAPI=2. Obsoleting EAPI=0
should occur when the decision to do so merely codifies the state of
the tree (at 90% EAPI>0, to pick a number ), at which point the
warning would be changed to an error. We could then use a couple of
bugdays to convert the remainder of the ebuilds or hand them over to
treecleaners if it's just unmaintained cruft.

In a year or so, we could change the repoman warning to trigger with
EAPI=1 also and make it point to EAPI=3 as the EAPI-of-choice.

> Deprecating EAPI1 at the same time would reduce the amount of EAPIs
> we have to think about, but since it has some changes like adding
> src_prepare migration would not be as trivial. So I'd prefer keeping
> it around a bit longer.
> 
> Comments?

We need to make this a part of the EAPI-upgrade process that
whenever a new EAPI is added, we consider including another EAPI in the
repoman warning. My hope is that at some point in the future (4 years?),
we'll be able to cut out some of the ugly phase hacks we have in many
eclasses that had EAPI=2 grafted onto them.

/loki_val

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

On Saturday 21 March 2009 22:26:41 Alec Warner wrote:
> >> > > Introducing a policy encouraging moving things that definitely
> >> > > aren't in the least bit likely to be a system dep on a bump, sure.
> >> > > Making 1 or 2 the default for new packages, sure. But rewriting
> >> > > existing things? That's just an accident waiting to happen.
> >> >
> >> > What kind of accident do you expect to happen?
> >>
> >> The same kind that always happens when lots of ebuilds get changed.
> >
> > ... lots of new features and a few bugs that get fixed the next day? Hey,
> > that sounds quite bad. And maybe some new herd testers? How rude!
>
> I don't see the correlation between EAPI bumps and new herd testers.

Well, ciaran said that the same thing happens that always happens when lots of 
ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice 
herd testers plus a new dev or two, so I am confused too. Maybe ciaran can 
explain what he meant to say so we don't have to come to unexpected 
conclusions (that would actually be a quite nice change to the average 
discussion - saying what you mean instead of hinting at star constellations 
and the importance of meat loaf)

> > So what technical reason(s) do we have to keep archaic EAPIs around
> > forever?
> None, luckily this is more than a technical project ;)

Stop confusing me, antarus, I thought you were against removing eapi0 and now 
you support the removal? ;)

Anyway. Most of the "porting" effort (assuming no other issues sneaking in) 
would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on 
version bumps. There's no rush to get it killed now now now, but in a year we 
might be at EAPI 5, and then I don't want to be the one writing the docs that 
split apart what features are where and what syntax is valid and all that.

So phasing out eapi0 would be an obvious step towards making things simpler 
for those of us that don't enjoy studying lists and tables ...


Patrick

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Sat, 21 Mar 2009 22:51:11 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> > >> The same kind that always happens when lots of ebuilds get
> > >> changed.
> > >
> > > ... lots of new features and a few bugs that get fixed the next
> > > day? Hey, that sounds quite bad. And maybe some new herd testers?
> > > How rude!
> >
> > I don't see the correlation between EAPI bumps and new herd testers.
> 
> Well, ciaran said that the same thing happens that always happens
> when lots of ebuilds get changed. Last time I saw that happen (think
> KDE4) we got some nice herd testers plus a new dev or two, so I am
> confused too.

And a massive amount of breakage, some of which still isn't fixed, yes.
Have a look at bugzilla sometime.

> Anyway. Most of the "porting" effort (assuming no other issues
> sneaking in) would be adding a "EAPI=1" line to ebuilds, which could
> be done "lazily" on version bumps. There's no rush to get it killed
> now now now, but in a year we might be at EAPI 5, and then I don't
> want to be the one writing the docs that split apart what features
> are where and what syntax is valid and all that.

Fortunately, you won't be. As the person who probably will be, I can
assure you that killing off EAPI 0 won't help in the slightest. It
won't mean we can remove all mention of EAPI 0 from the documentation,
since package managers need to support EAPIs indefinitely for
uninstalls.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Alec Warner]

On Sat, Mar 21, 2009 at 2:51 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On Saturday 21 March 2009 22:26:41 Alec Warner wrote:
>> >> > > Introducing a policy encouraging moving things that definitely
>> >> > > aren't in the least bit likely to be a system dep on a bump, sure.
>> >> > > Making 1 or 2 the default for new packages, sure. But rewriting
>> >> > > existing things? That's just an accident waiting to happen.
>> >> >
>> >> > What kind of accident do you expect to happen?
>> >>
>> >> The same kind that always happens when lots of ebuilds get changed.
>> >
>> > ... lots of new features and a few bugs that get fixed the next day? Hey,
>> > that sounds quite bad. And maybe some new herd testers? How rude!
>>
>> I don't see the correlation between EAPI bumps and new herd testers.
>
> Well, ciaran said that the same thing happens that always happens when lots of
> ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice
> herd testers plus a new dev or two, so I am confused too. Maybe ciaran can
> explain what he meant to say so we don't have to come to unexpected
> conclusions (that would actually be a quite nice change to the average
> discussion - saying what you mean instead of hinting at star constellations
> and the importance of meat loaf)
>
>> > So what technical reason(s) do we have to keep archaic EAPIs around
>> > forever?
>> None, luckily this is more than a technical project ;)
>
> Stop confusing me, antarus, I thought you were against removing eapi0 and now
> you support the removal? ;)

Editing 20000 ebuilds is not 'technical' in nature, its grunt work.
It is a social problem, not a technical one.
I also haven't stated my support in either direction since you have
provided no specific arguments as to why we should do this; there is
nothing to argue against.

>
> Anyway. Most of the "porting" effort (assuming no other issues sneaking in)
> would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on
> version bumps. There's no rush to get it killed now now now, but in a year we
> might be at EAPI 5, and then I don't want to be the one writing the docs that
> split apart what features are where and what syntax is valid and all that.

Or we might be at EAPI 3; we have no EAPI roadmap and I don't like
guessing.  Again I'm looking for specifics here.  You are asking the
community to do a lot of work for relatively little gain; because you
haven't specified what the gain is.  So I ask again "What specific
problems does this solve?"

>
> So phasing out eapi0 would be an obvious step towards making things simpler
> for those of us that don't enjoy studying lists and tables ...
>
>
> Patrick
>
>
>

Re: [gentoo-dev] RFC: Deprecating EAPI0

[AllenJB]

Patrick Lauer wrote:
> Hi all,
> 
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you 
> count them ;) ) EAPIs available or almost available. This is getting quite 
> confusing.
> To make our lives easier I would suggest deprecating EAPI0 and migrating 
> existing ebuilds over some time to EAPI1 or higher until EAPI0 can be 
> obsoleted at some point in the future.
> I would set the start of deprecation warnings about 3 months from now and the 
> obsoletion quite a time later, maybe 12 months from now, when a sufficient 
> amount of ebuilds has been migrated.
> 
> Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to 
> think about, but since it has some changes like adding src_prepare migration 
> would not be as trivial. So I'd prefer keeping it around a bit longer.
> 
> Comments?
> 
> 
> Patrick 
> 

While there definitely arguments for deprecating EAPIs, I would suggest 
caution.

A low number of active EAPIs can make life easier for developers, but it 
can also make life harder for some users. There are still users coming 
to the forums upgrading systems which only understand EAPI 0. I accept 
that Gentoo is certainly a relatively fast moving distro, but I think 
that developers also do need to consider users who have systems that are 
currently "just working" and may not upgrade often (once a year or even 
less).

As such, I would suggest that forcing a move to the most recent stable 
EAPI is possibly unwise.

I believe that forcing EAPIs to move forward at too quick a pace will 
cause more issues for these users. An answer to this could be to set a 
standard for the minimum time between upgrades - for example, 1 year - 
and ensure that users with anything that old can atleast upgrade portage 
and its dependencies to the minimum required versions without major issues.

I understand that this may cause extra work in some respects, but if 
such a standard is set and documented then it will help users (admins) 
by giving them a set frequency at which they must upgrade at least the 
package manager, if not @system.


Secondly, it was suggested that a project to upgrade all ebuilds in the 
tree from EAPI 0 could bring new developers, offering KDE4 as an 
example. I would offer caution on this assumption. KDE4 was not simply 
about upgrading ebuilds, but about users (contributors) and developers 
being able to install and test packages they wanted to install and test. 
I can not realistically see such an effort being asserted in the name of 
simply deprecating EAPIs.

Yes, breakage occurred, but this was as far as I can see a complete 
rewrite of the KDE packaging from scratch. As such I would suggest that 
a certain level of breakage was to be expected. I would also suggest 
that the speed at which bugs are being fixed may be more of an indicator 
of lack of man power than anything else, and that the situation could be 
improved by looking at expending more effort on encouraging 
contributions and ultimately recruiting developers. I realize that 
getting people to expend effort on non-coding work can be difficult, but 
I think that ultimately the effort expended will be repaid in terms of 
extra contributions.


In general, I would have to agree with those who believe there are 
currently better ways to expend effort within Gentoo. As such I would 
suggest that at most, EAPI deprecation only applies to new packages and 
version bumps.

AllenJB

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Robert R. Russell]

On Saturday 21 March 2009 19:03:45 AllenJB wrote:
> Patrick Lauer wrote:
> > Hi all,
> >
> > with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> > count them ;) ) EAPIs available or almost available. This is getting
> > quite confusing.
> > To make our lives easier I would suggest deprecating EAPI0 and migrating
> > existing ebuilds over some time to EAPI1 or higher until EAPI0 can be
> > obsoleted at some point in the future.
> > I would set the start of deprecation warnings about 3 months from now and
> > the obsoletion quite a time later, maybe 12 months from now, when a
> > sufficient amount of ebuilds has been migrated.
> >
> > Deprecating EAPI1 at the same time would reduce the amount of EAPIs we
> > have to think about, but since it has some changes like adding
> > src_prepare migration would not be as trivial. So I'd prefer keeping it
> > around a bit longer.
> >
> > Comments?
> >
> >
> > Patrick
>
> While there definitely arguments for deprecating EAPIs, I would suggest
> caution.
>
> A low number of active EAPIs can make life easier for developers, but it
> can also make life harder for some users. There are still users coming
> to the forums upgrading systems which only understand EAPI 0. I accept
> that Gentoo is certainly a relatively fast moving distro, but I think
> that developers also do need to consider users who have systems that are
> currently "just working" and may not upgrade often (once a year or even
> less)
>
> As such, I would suggest that forcing a move to the most recent stable
> EAPI is possibly unwise.
>
<snip>
> AllenJB

Note, this just my opinion. It may not be entirely practical or cover all the 
issues regarding backwards compatibility. I intend it to provoke questions 
and thought as to what a reasonable policy for backwards compatibility might 
cover.

Waiting a year or longer to upgrade a gentoo system carries a good risk of 
having something explode into a near unrecoverable mess.

I definitely do think that some major focus needs to be placed on how far 
behind a gentoo system could be and should still be expected to catch up.

An oversimplified example. Assume that I can find all required patches and 
source code to do the initial builds, and that all normal configuration file 
checks/updates are done after the current tree is installed.

I create three different virtual machines from cvs snapshots of the portage 
tree. The first is dated 6 months ago. The second is dated 12 months ago. The 
third is dated 18 months ago.

Which of these should be reasonably updateable to the current portage tree?

My suggestion is that policy should allow machine 1 to be updated through 
regular update procedures to the current tree, unless major changes dictate 
otherwise. Major changes being incompatible ebuild formats, toolchains, and 
other here is the line sorry kind of changes.

A careful operator should probably be able get machine 2 updated to the 
current tree, again unless major changes dictate otherwise. We should not 
make go out of our way to make upgrading from this point out hard for the 
operator, but, new growth should be favored over the ease of upgrading.

Machine 3 is just out of luck. Here is the new install cd and handbook, have 
fun.

Regular update procedures would be:
emerge --sync; emerge -uND world -f; emerge -uND world; revdep-rebuild; 
emerge --depclean;

The careful operator might update the toolchain first and emerge -e world or 
something similar.

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Matti Bickel]

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

Peter Alfredsen <loki_val@gentoo.org> wrote:
> I think we should start
> deprecating EAPI=0 usage *now* with a repoman warning whenever a new
> ebuild is committed that does not use EAPI=1 or EAPI=2. This warning
> should encourage use of the newest EAPI, EAPI=2.

A general question, that just popped into my head when i was reading
this: if i touch a ebuild which has EAPI=0, should i bump it to EAPI=2?
Since the introduction of EAPI i have been bumping EAPI of my ebuilds
based on need. So if i needed slot-deps, i've made the ebuild EAPI=1,
not EAPI=2 by choice. If i needed use-deps, then well, i went for
EAPI=2.

How are other ebuild developers doing this? What's the package manager
ppls take on this?
-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Peter Alfredsen]

On Sun, 22 Mar 2009 09:41:58 +0100
Matti Bickel <mabi@gentoo.org> wrote:

> A general question, that just popped into my head when i was reading
> this: if i touch a ebuild which has EAPI=0, should i bump it to
> EAPI=2?

Only if you take the time to read through it and test that your revised
ebuild will have the same functionality as the old one. That's why I
wrote "when a new ebuild...". This should not be an automated thing,
but rather a part of the basic bump-adjust-test maintenance cycle.

/loki_val

EAPI roadmap (was: Re: [gentoo-dev] RFC: Deprecating EAPI0)

[Thilo Bangert]

Peter Alfredsen <loki_val@gentoo.org> said:
> On Sun, 22 Mar 2009 09:41:58 +0100
>
> Matti Bickel <mabi@gentoo.org> wrote:
> > A general question, that just popped into my head when i was reading
> > this: if i touch a ebuild which has EAPI=0, should i bump it to
> > EAPI=2?
>
> Only if you take the time to read through it and test that your revised
> ebuild will have the same functionality as the old one. That's why I
> wrote "when a new ebuild...". This should not be an automated thing,
> but rather a part of the basic bump-adjust-test maintenance cycle.
>

while i agree with what you say here, it is also important to take the 
general EAPI roadmap  into account. as we currently dont have one AFAIK, 
we should make efforts to agree on one soon.

i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to 
have en EAPI=2 capable package manager stable within a reasonable 
timeframe.

as it really doesnt matter what i think, when portage-2.2 should go stable 
i will not bore you with that, however, given that only portage 2.2 
supports EAPI=2 it is relevant for the discussion of an EAPI roadmap.

in light of the current EAPI usage statistics, i would propose to 
deprecate EAPI 1 (and 2) much earlier than EAPI 0.

regards
Thilo

> /loki_val

[gentoo-dev] Re: EAPI roadmap

[Serkan Kaba]

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

Thilo Bangert yazmış:
> i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to 
> have en EAPI=2 capable package manager stable within a reasonable 
> timeframe.
2.1.6 is stable and supports EAPI2

- --
Sincerely,
Serkan KABA
Gentoo Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknGHSsACgkQRh6X64ivZaKlRwCfRqdpdvroDZN0OQOycCo1N6Qi
rjcAnRzNxfxQ6SK2pmFRzWbiLYR1rGwW
=LZcB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Dawid Węgliński]

On Saturday 21 of March 2009 21:53:16 Patrick Lauer wrote:
> On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote:
> > On Sat, 21 Mar 2009 18:37:12 +0100
> >
> > Patrick Lauer <patrick@gentoo.org> wrote:
> > > To make our lives easier I would suggest deprecating EAPI0 and
> > > migrating existing ebuilds over some time to EAPI1 or higher until
> > > EAPI0 can be obsoleted at some point in the future.
> >
> > Uh. Why?
>
> Because, as you have noticed before, developers get confused which eapi has
> which features available. And eapi1 is a superset of eapi0, so we don't
> have to rewrite tons of things.
>

Spend more time to teach them. It's easier to developers make sure they do 
things ok than users spending their time to figure out what's wrong.

Personally i don't like the idea of deprecating EAPI0 since it may break many 
servers. Eg. our border router at work isn't upgraded regulary. I spent much 
time lately to upgrade it with problems like portage vs. bash and so.

So the last thing i'd like to see now in portage is implementing your 
proposal.

> > Introducing a policy encouraging moving things that definitely aren't
> > in the least bit likely to be a system dep on a bump, sure. Making 1 or
> > 2 the default for new packages, sure. But rewriting existing things?
> > That's just an accident waiting to happen.
>
> What kind of accident do you expect to happen?
>
> Patrick

Re: [gentoo-dev] Re: EAPI roadmap

[Thilo Bangert]

Serkan Kaba <serkan@gentoo.org> said:
> Thilo Bangert yazmış:
> > i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont
> > expect to have en EAPI=2 capable package manager stable within a
> > reasonable timeframe.
>
> 2.1.6 is stable and supports EAPI2

thats pretty cool. thanks...

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Luca Barbato]

Patrick Lauer wrote:
[deprecating stuff]

I'd rather switch to git first, have eapi in separate branches then, 
make sure we can provide eapi-N compatibility/migration tree snapshots
and then warn people so there will be a easy way to provide fallbacks.

Before that I'm afraid it would take too much.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Tue, 24 Mar 2009 12:40:05 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> I'd rather switch to git first, have eapi in separate branches then, 
> make sure we can provide eapi-N compatibility/migration tree snapshots
> and then warn people so there will be a easy way to provide fallbacks.

Uhm. Do you think these ideas of yours through at all before posting
them?

Either you think the entire tree should be switched to a new EAPI in
one go, in which case how on earth is that going to get done, or you
don't, in which case there's no point to branches, and any migration
can be done using a simple tag.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Luca Barbato]

Ciaran McCreesh wrote:
> Uhm. Do you think these ideas of yours through at all before posting
> them?

Being rude doesn't make you cool. (Nor make your points more effective)

> Either you think the entire tree should be switched to a new EAPI in
> one go, in which case how on earth is that going to get done, or you
> don't, in which case there's no point to branches, and any migration
> can be done using a simple tag.

I'd like you to rethink your statement and then come again.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Wed, 25 Mar 2009 10:19:12 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Uhm. Do you think these ideas of yours through at all before posting
> > them?
> 
> Being rude doesn't make you cool. (Nor make your points more
> effective)

That's not being rude. It's an attempt to bring your attention to the
fact that other people read what you right, so you're doing them a
discourtesy by wasting their time by repeatedly posting ideas you
haven't thought through and that aren't even remotely workable.

> > Either you think the entire tree should be switched to a new EAPI in
> > one go, in which case how on earth is that going to get done, or you
> > don't, in which case there's no point to branches, and any migration
> > can be done using a simple tag.
> 
> I'd like you to rethink your statement and then come again.

We've been over this before. The whole point of EAPI is that it avoids
the need for mass tree changes.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Maciej Mrozowski]

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

On Wednesday 25 of March 2009 15:19:36 Ciaran McCreesh wrote:

> > Being rude doesn't make you cool. (Nor make your points more
> > effective)
>
> That's not being rude.
[...]
(no comment)

> so you're doing them a
> discourtesy by wasting their time by repeatedly posting ideas you
> haven't thought through
[...]
Considering average post count and Gentoo membership on that list, I'm pretty 
convinced you're not entitled to decide who is wasting developers' time.

-- 
regards
MM

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Ciaran McCreesh]

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

On Wed, 25 Mar 2009 20:06:47 +0100
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> Considering average post count and Gentoo membership on that list,
> I'm pretty convinced you're not entitled to decide who is wasting
> developers' time.

When you've gained enough experience and knowledge to be able to
evaluate the merits of proposals, I invite you to rethink those
comments and deliver your apology.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Alec Warner]

On Wed, Mar 25, 2009 at 12:13 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 25 Mar 2009 20:06:47 +0100
> Maciej Mrozowski <reavertm@poczta.fm> wrote:
>> Considering average post count and Gentoo membership on that list,
>> I'm pretty convinced you're not entitled to decide who is wasting
>> developers' time.
>
> When you've gained enough experience and knowledge to be able to
> evaluate the merits of proposals, I invite you to rethink those
> comments and deliver your apology.

Please feel free to continue this conversation off list (both sides).
If you want to call people rude farts, do it on your own time, not on
my list.

-A

>
> --
> Ciaran McCreesh
>