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


 
 
LinkBack Thread Tools
 
Old 09-02-2012, 10:52 AM
Vaeth
 
Default EAPI usage

Rich Freeman <rich0@gentoo.org> wrote:


If I thought that bumping the EAPI would make my life as a maintainer
easier I'd just do it - I wouldn't need a policy to tell me to do it.


It is not only so much a question of whether it helps you as a
maintainer but more whether it helps the user. And this is the case
for all EAPIs which currently exist.

I am surprised that nobody mentioned the following example:

One of the arguments to introduce the user-patching code into EAPI=5
was that it should work for all packages - not randomly on some but
not on others. So if in the course of time not all packages are
bumped to at least EAPI=5, this goal cannot be reached by introducing
the feature into the EAPI.


If I did think that bumping the EAPI wasn't worth the hassle, and yet
I was told that I'd be banned as a dev for not doing so anyway, then
obviously I'm going to do the minimum necessary to comply with policy,
which means changing the EAPI line of the ebuild and only changing
other lines as required to get the thing to build and comply with PMS.


This is sufficient for 99% of the ebuilds.


So, while all those benefits you named are "enabled" few would
actually be realized.


For current EAPIs, most benefits are realized just by bumping EAPI.
For instance, the improved error checking (i.e. dying on certain problems)
happens automatically and might reveal problems which were hidden before.

Also, for EAPI=5, other packages (possibly from overlays) can make use
of slot dependencies from your packages.

OK, for changing from setup tests for USE dependencies and USE_REQUIRE
may require some extra coding (though not much), but again it is
the _user_ who will gain from it a lot.

So in any case, for the _user_ an EAPI bump is (with the current EAPIs)
always a benefit. This should be worth to establish the policy currently.

If this happens to be different in some hypothetical future EAPIs,
this policy can be modified later, correspondingly: It is easy to
change this policy later on, but hard to bump the whole tree later on.

Martin Všth
 
Old 09-02-2012, 11:13 AM
Rich Freeman
 
Default EAPI usage

On Sun, Sep 2, 2012 at 6:52 AM, Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> So in any case, for the _user_ an EAPI bump is (with the current EAPIs)
> always a benefit. This should be worth to establish the policy currently.

Your example only cited cases where an EAPI bump to 5 has a benefit.
If that is the case, I'm fine with making an effort to migrate as many
ebuilds as possible to EAPI 5.

However, what is the benefit to users from migrating to EAPI 1, or 2,
etc? The policy you're recommending would have required expending
effort to implement every one of those for every ebuild in the tree
without those kinds of end-user benefits.

What will the benefit be for migrating to EAPI 6, or 7, or fred (EAPIs
are not numbers, and they aren't ordered either)? And since EAPIs
aren't actually ordered, is the latest one whichever is actually last
approved, or the one which is "most functional?" Suppose EAPI xml
defines an ebuild format in xml that isn't parsed by bash, whose
purpose is mainly to allow simple ebuilds to be simplified further but
which is really only appropriate for 20% of the ebuilds in the tree?
It isn't good to assume that newer EAPIs include all the features of
the earlier ones - they just are different specifications for
behavior. Maybe somebody will come up with a reason to have an EAPI
that only works with packages that use cmake for building, or
whatever. The bottom line is that it may be desirable in the future
to have different branches of EAPIs followed by different packages.

So, if we want to make a policy that we should use EAPI5 whenever
possible I'm fine with that, if the benefits to users are worth the
costs. However, why extend this to every EAPI that follows when the
benefits of those are not yet known?

Let's look at a different situation - --as-needed. It was realized
that supporting this across the tree has significant benefits for
users, so we made a push to make it happen. Packages that didn't
support this had bugs filed, and they were fixed, and today it is the
default. However, what we DIDN'T do is just make a policy that all
packages have to support all possible options in LDFLAGS, but rather
we just focused on the one we actually cared about.

You don't even need a "policy" to enact these kinds of changes. There
was never a policy that all ebuilds must support --as-needed, and
there may be legitimate reasons for individual packages to not support
it today. However, when the case was made that this benefits
end-users then everybody just jumped on board, since, well, most of us
are nice guys who do that sort of thing.

Rich
 
Old 09-02-2012, 12:03 PM
hasufell
 
Default EAPI usage

On 09/02/2012 12:52 PM, Vaeth wrote:
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> If I thought that bumping the EAPI would make my life as a maintainer
>> easier I'd just do it - I wouldn't need a policy to tell me to do it.
>
> It is not only so much a question of whether it helps you as a
> maintainer but more whether it helps the user. And this is the case
> for all EAPIs which currently exist.
>
> I am surprised that nobody mentioned the following example:
>
> One of the arguments to introduce the user-patching code into EAPI=5
> was that it should work for all packages - not randomly on some but
> not on others. So if in the course of time not all packages are
> bumped to at least EAPI=5, this goal cannot be reached by introducing
> the feature into the EAPI.

global epatch_user has a downside which I think was not even really
discussed here unless I missed something. It could introduce many bogus
bug reports which are caused by user-applied patches, cause it's easier
now and you don't need to do it in an overlay.
The maintainer will need to catch this and asking which repo the
bugreporter did use is not sufficient. He will need the build log and
check if user patches got applied there.

Always talking about the benefit for the user and not the time
developers have to spend on things does not catch the whole situation.

>> If I did think that bumping the EAPI wasn't worth the hassle, and yet
>> I was told that I'd be banned as a dev for not doing so anyway, then
>> obviously I'm going to do the minimum necessary to comply with policy,
>> which means changing the EAPI line of the ebuild and only changing
>> other lines as required to get the thing to build and comply with PMS.
>
> This is sufficient for 99% of the ebuilds.

PMS is a fraction of what is to consider when writing an ebuild. It does
not include QA policies, gentoo policies and whatnot.

>
>> So, while all those benefits you named are "enabled" few would
>> actually be realized.
>
> For current EAPIs, most benefits are realized just by bumping EAPI.
> For instance, the improved error checking (i.e. dying on certain problems)
> happens automatically and might reveal problems which were hidden before.

dying on certain problems can be achieved without EAPI bump.

>
> Also, for EAPI=5, other packages (possibly from overlays) can make use
> of slot dependencies from your packages.
>
> OK, for changing from setup tests for USE dependencies and USE_REQUIRE
> may require some extra coding (though not much), but again it is
> the _user_ who will gain from it a lot.
>

If a user wants/needs features of newer EAPIs, because he does some
things in his overlay, he could probably open a bug report with a
proposed patch to the ebuild which bumps the EAPI.

Unless that's the case I would leave it to the developer if he needs
those features or what EAPI he prefers. If a newer EAPI would fix a bug
it might still be solvable without EAPI-bump. Again: leave it to the
developer.

This will create a useless annoyance and I can assure you that
developers WILL ignore this policy/rule. What are you gonna do then?
Just bump it on your own without asking? Take it up to devrel?
It's not really worth it.

The benefits have been stated and it's already advised that developers
keep up with the latest EAPI, but you _cannot_ assume it anyway like
some PMS contributors do.
 
Old 09-02-2012, 12:33 PM
Rich Freeman
 
Default EAPI usage

On Sun, Sep 2, 2012 at 8:03 AM, hasufell <hasufell@gentoo.org> wrote:
> PMS is a fraction of what is to consider when writing an ebuild. It does
> not include QA policies, gentoo policies and whatnot.

True, although at least somebody bothers to write PMS down...

Much of the rest is word of mouth, posts on mailing lists, maybe
council meeting minutes, and whatever somebody decides to put in a bug
report or ping you with on IRC. There are the GLSAs, and then stuff
like guides and the devmanual, which are a blend of must-do, best
practices (which presumably are discretionary), and just illustrative
examples.

Bottom line is that what a developer MUST do is a matter of what
people will bother to complain to Devrel about, and what Devrel will
bother to enforce. For the most part this boils down to common sense.
That's why most "developers must do foo" proposals don't end up going
anywhere. In six months somebody new will join the project and not
even know what they "must" do simply by virtue of the fact that we
won't bother to write it down anyway.

Rich
 
Old 09-02-2012, 01:10 PM
"Andreas K. Huettel"
 
Default EAPI usage

> > <rant>
[...]
> > standards. So, we declare that gcc-4.5 has to be enough for everyone,
> > we'll just keep it in tree forever and dont bother anymore with all
> > these superfluous "does not build with gcc-4.7" bugs.
>
> That is not an appropriate analogy, as I'm not suggesting that we
> refuse to support newer EAPIs. I'm just saying that packages
> shouldn't be bumped just for the sake of bumping them.

Well I'm also not "suggesting" that we refuse to support newer gcc. Just, if a
package does not build with newer, meh, why care. Take old one.
</rant>

> I might see some benefit for devs who routinely modify stuff that they
> don't maintain, but that should generally be kept to a minimum anyway.
> If unsure how how to edit any particular ebuild, just file a bug!
> And if the package isn't maintained, then nobody will be bumping its
> EAPI anyway.

True but... we do have some fluctuation, and developers come and go. Who can
update the ebuild better, someone who has maintained it for a while and is
familiar with its details and the current eapis, or someone who has just
picked up its pieces.

What I dont actually understand at all is why bumping the EAPI should be so
complicated or involved that it even deserves so much resistance...

OK there may be miraculous eclasses (or one in particular) which change api
radically from eapi to eapi, but I think we've already decided long time ago
that this is a bad thing(tm) and should not be done. So let's hope it will not
happen again.

Other than that, I can not remember any ebuild where the EAPI bump alone took
me more than 5min. Now take the frequency of new eapi's coming out, and
compare it with the time that you need for a version bump of a package anyway
(check upstream changelog, verify dependencies have not changed, do a test
build, check for correct installation locations, ...)

As an additional bonus this keeps your memory fresh about all the great new
features...

Cheers,
Andreas

--

Andreas K. Huettel
Gentoo Linux developer
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 09-02-2012, 01:23 PM
"Andreas K. Huettel"
 
Default EAPI usage

> Bottom line is that what a developer MUST do is a matter of what
> people will bother to complain to Devrel about, and what Devrel will
> bother to enforce. For the most part this boils down to common sense.

Err... if that's the part you worry about, I'm personally completely happy if
we just all agree that it's common sense to stick to the newest council-
approved development with fullest feature set. no need to put it in writing
any more than as a "strong recommendation".

> And since EAPIs
> aren't actually ordered, is the latest one whichever is actually last
> approved, or the one which is "most functional?" Suppose EAPI xml

To be honest I personally consider that ("eapis are not ordered") an
abomination, and my personal wish would be to keep them large-scale ordered
with (among one major version) unordered sub-versions ("4-xxx") if needed. or
at least keep all PMS-approved eapis ordered. "Experimental eapis for use in
third party software" should not require any mentioning in pms anyway. :]

However, that is a different discussion. Someday I'll start a separate
flamewar^H^H^H^H^H^H^Hmailing list thread about it.

--

Andreas K. Huettel
Gentoo Linux developer
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 09-02-2012, 01:46 PM
Rich Freeman
 
Default EAPI usage

On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> What I dont actually understand at all is why bumping the EAPI should be so
> complicated or involved that it even deserves so much resistance...

<rant>Ok, it REALLY annoys me when people pull out this kind of a line
in an argument... If it isn't all that complicated or involved and it
just makes so much sense, then why do we bother to waste time asking
for it to be made policy, since obviously everybody will just do it
anyway...

Believe it or not, people who take up an opposing side in a debate
don't ALWAYS do it because they're simply dumber than you. That is,
unless they're arguing with me... </rant>

>
> As an additional bonus this keeps your memory fresh about all the great new
> features...

Yes, but keeping around all those old EAPIs keeps your memory fresh
about how those ones work. As an additional bonus, you don't have to
bother to figure out how the new ones work unless you actually need a
feature offered by them.

Rich
 
Old 09-02-2012, 02:36 PM
Michael Orlitzky
 
Default EAPI usage

On 09/02/2012 09:46 AM, Rich Freeman wrote:
> On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> What I dont actually understand at all is why bumping the EAPI should be so
>> complicated or involved that it even deserves so much resistance...
>
> <rant>Ok, it REALLY annoys me when people pull out this kind of a line
> in an argument... If it isn't all that complicated or involved and it
> just makes so much sense, then why do we bother to waste time asking
> for it to be made policy, since obviously everybody will just do it
> anyway...
>
> Believe it or not, people who take up an opposing side in a debate
> don't ALWAYS do it because they're simply dumber than you. That is,
> unless they're arguing with me... </rant>
>


I think everyone would be happier if all ebuilds in the tree were EAPI4.
On the other hand, Rich is right that making this a policy will have the
opposite of the intended effect: developers just won't fix bugs in
EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could
easily spend a few hours on this).

As a compromise, it could be made policy that "bump to EAPI=foo" bugs
are valid. If someone would benefit from such a bump, he can file a bug
and know that it won't be closed WONTFIX. On the other hand, the dev is
under no more pressure than usual to do the bump.
 
Old 09-02-2012, 05:54 PM
Alexis Ballier
 
Default EAPI usage

On Sun, 02 Sep 2012 14:03:07 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 09/02/2012 12:52 PM, Vaeth wrote:
> > Rich Freeman <rich0@gentoo.org> wrote:
> >
> >> If I thought that bumping the EAPI would make my life as a
> >> maintainer easier I'd just do it - I wouldn't need a policy to
> >> tell me to do it.
> >
> > It is not only so much a question of whether it helps you as a
> > maintainer but more whether it helps the user. And this is the case
> > for all EAPIs which currently exist.
> >
> > I am surprised that nobody mentioned the following example:
> >
> > One of the arguments to introduce the user-patching code into EAPI=5
> > was that it should work for all packages - not randomly on some but
> > not on others. So if in the course of time not all packages are
> > bumped to at least EAPI=5, this goal cannot be reached by
> > introducing the feature into the EAPI.
>
> global epatch_user has a downside which I think was not even really
> discussed here unless I missed something. It could introduce many
> bogus bug reports which are caused by user-applied patches, cause
> it's easier now and you don't need to do it in an overlay.
> The maintainer will need to catch this and asking which repo the
> bugreporter did use is not sufficient. He will need the build log and
> check if user patches got applied there.

it is probably easy to add a big warning 'user patches have been
applied' when emerge bails out because a build failed
 
Old 09-02-2012, 06:02 PM
Ciaran McCreesh
 
Default EAPI usage

On Sun, 02 Sep 2012 14:03:07 +0200
hasufell <hasufell@gentoo.org> wrote:
> global epatch_user has a downside which I think was not even really
> discussed here unless I missed something. It could introduce many
> bogus bug reports which are caused by user-applied patches, cause
> it's easier now and you don't need to do it in an overlay.
> The maintainer will need to catch this and asking which repo the
> bugreporter did use is not sufficient. He will need the build log and
> check if user patches got applied there.

No, it's not a downside. It's an advantage: user patches will get
applied correctly now, and in a way visible to the package mangler, and
thus can be shown consistently in bug reports.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 12:37 PM.

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