FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-21-2009, 08:06 PM
Ciaran McCreesh
 
Default RFC: Deprecating EAPI0

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
 
Old 03-21-2009, 08:26 PM
Alec Warner
 
Default RFC: Deprecating EAPI0

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
>
>
 
Old 03-21-2009, 08:35 PM
Peter Alfredsen
 
Default RFC: Deprecating EAPI0

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
 
Old 03-21-2009, 08:51 PM
Patrick Lauer
 
Default RFC: Deprecating EAPI0

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
 
Old 03-21-2009, 08:55 PM
Ciaran McCreesh
 
Default RFC: Deprecating EAPI0

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
 
Old 03-21-2009, 09:23 PM
Alec Warner
 
Default RFC: Deprecating EAPI0

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
>
>
>
 
Old 03-21-2009, 11:03 PM
AllenJB
 
Default RFC: Deprecating EAPI0

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
 
Old 03-22-2009, 07:19 AM
"Robert R. Russell"
 
Default RFC: Deprecating EAPI0

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.
 
Old 03-22-2009, 07:41 AM
Matti Bickel
 
Default RFC: Deprecating EAPI0

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)
 
Old 03-22-2009, 08:22 AM
Peter Alfredsen
 
Default RFC: Deprecating EAPI0

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
 

Thread Tools




All times are GMT. The time now is 08:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org