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 08-30-2012, 01:27 PM
"Andreas K. Huettel"
 
Default EAPI usage

Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
> Could you elaborate what the reasons FOR it are (not that I don't know
> any, but you brought it up) since this will add work for every developer
> to check a) how the behavior of the new EAPI impacts the current ebuild
> and b) how the behvaior of inherited eclasses change depending on EAPI.

a) Easier eclass maintenance.
Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler.
We'll raise that to 4 only soon (after fixing the remaining ebuilds in the
tree.)

b) Easier overall tree maintenance.
I've recently removed a useflag on poppler (xpdf-headers for those
interested). Of course, this involved fixing all in-tree reverse dependencies
first. Now I consider myself very lucky there, because all except two packages
were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously
bumped it to 4. One was EAPI 0. Having fun with || there.

I dont consider this list complete, feel free to add.

--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 08-30-2012, 01:28 PM
Michael Mol
 
Default EAPI usage

On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>>
>> The primary benefit to the policy that dev's should bump EAPI when
>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>> eventually removed from the tree.
>
> What is the benefit from removing the old EAPIs?

I can answer this one...removing old EAPIs simplifies code for things
which need to be EAPI-aware. There are no bugs in code that doesn't
exist.

--
:wq
 
Old 08-30-2012, 01:33 PM
Ian Stakenvicius
 
Default EAPI usage

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

On 30/08/12 09:14 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
>>
>> The primary benefit to the policy that dev's should bump EAPI
>> when bumping ebuilds is so that older inferior EAPIs can be
>> deprecated and eventually removed from the tree.
>
> What is the benefit from removing the old EAPIs?

Simpler eclasses is the first thing that comes to mind. Consistency
in the way the dependency tree is built would be another (when newer
EAPIs address such things, that is)

>
> Simply bumping an ebuild to EAPI=5 doesn't even guarantee that
> either of those features would be used anyway.

..although this could technicaly be true, I think most developers
would assume that bumping EAPI doesn't mean changing the EAPI variable
from whatever to 5 and that's it; the "bump" should involve
integrating any applicable features that the new EAPI offers.

>
> If there is a benefit from some specific practice, then let's
> adopt it. However, I don't think that is the same as just bumping
> EAPIs for their own sake.
>
> When there is a benefit to adopting a new EAPI of course
> maintainers should try to take advantage of it. If there are
> specific changes we want to try to make tree-wide let's try to do
> that too. But, why bump ebuilds from 0 to 1 to 2 to 3 to 4 to 5
> when your only example of an end-user benefit would have been
> achieved if we just bumped from 0 to 5 in one step?


We used to have a policy that the oldest EAPI that implements all
features needed for an ebuild is the one that should be used. Now (as
of when EAPI=4 was made official i think?) it's the reverse -- the
newest (official) EAPI is the one that should be used. All this
policy change suggestion scarabeus provided is doing, is recommending
that developers bump EAPI when they bump their ebuilds, as compared to
only when writing new ones (which is all the current policy would
require us to do).

if you want another example, i'm sure end-user benefits would have
ensued if many existing packages that die in pkg_setup were bumped to
EAPI=4 right away and their checks moved to pkg_pretend. Examples
prior to EAPI=4 are irrelevent as the policy was different then.

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

iF4EAREIAAYFAlA/a6sACgkQ2ugaI38ACPBO5wD+JSBmTT3j0MFc1GMjIDatRLnV
J7Oj3rQWjS3GKpU8pQgBALsVg7R1QGGjETv0KS3j9yxBlflr4P lKECboVXqoRupL
=+zxo
-----END PGP SIGNATURE-----
 
Old 08-30-2012, 07:44 PM
Thomas Sachau
 
Default EAPI usage

Andreas K. Huettel schrieb:
> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>> Could you elaborate what the reasons FOR it are (not that I don't know
>> any, but you brought it up) since this will add work for every developer
>> to check a) how the behavior of the new EAPI impacts the current ebuild
>> and b) how the behvaior of inherited eclasses change depending on EAPI.
>
> a) Easier eclass maintenance.
> Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler.
> We'll raise that to 4 only soon (after fixing the remaining ebuilds in the
> tree.)

An eclass, which includes helper commands like eutils or versionator
eclass wont benefit from it. Only specific eclasses (like your kde
example would benefit and for those, the related team can always decide
to bump all their packages to the wanted EAPI and then to bump the
eclass requirement. So no need to force this on everyone else.

>
> b) Easier overall tree maintenance.
> I've recently removed a useflag on poppler (xpdf-headers for those
> interested). Of course, this involved fixing all in-tree reverse dependencies
> first. Now I consider myself very lucky there, because all except two packages
> were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously
> bumped it to 4. One was EAPI 0. Having fun with || there.

If a package has a maintainer, you could just ask him to fix the issue,
so you dont have to even think about the EAPI. And if there is no
maintainer, you can take and bump it. And if noone wants to maintain it,
it will be dropped at some point. So you can bump whatever you maintain,
just still the question: Why force this on everyone else?


--

Thomas Sachau
Gentoo Linux Developer
 
Old 08-30-2012, 07:47 PM
Thomas Sachau
 
Default EAPI usage

Michael Mol schrieb:
> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>>>
>>> The primary benefit to the policy that dev's should bump EAPI when
>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>>> eventually removed from the tree.
>>
>> What is the benefit from removing the old EAPIs?
>
> I can answer this one...removing old EAPIs simplifies code for things
> which need to be EAPI-aware. There are no bugs in code that doesn't
> exist.
>

Like package managers?

Sorry, but this is not true, since you can never assume, that older
EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never
needed a bump, is enough), so older EAPI versions have to be supported
forever.

--

Thomas Sachau
Gentoo Linux Developer
 
Old 08-30-2012, 08:05 PM
Michael Mol
 
Default EAPI usage

On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> Michael Mol schrieb:
>> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
>>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>>>>
>>>> The primary benefit to the policy that dev's should bump EAPI when
>>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>>>> eventually removed from the tree.
>>>
>>> What is the benefit from removing the old EAPIs?
>>
>> I can answer this one...removing old EAPIs simplifies code for things
>> which need to be EAPI-aware. There are no bugs in code that doesn't
>> exist.
>>
>
> Like package managers?
>
> Sorry, but this is not true, since you can never assume, that older
> EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never
> needed a bump, is enough), so older EAPI versions have to be supported
> forever.

I would assume that's what auditing is for. Unless I'm sorely mistaken
(and I may be; I don't know much at all about eclasses), it should be
fairly simple to script through the tree to find any eclasses or
ebuilds which express a dependency on an EAPI of a given level,
presuming the expression is of a standard form.

Compile a list of existing ebuilds which depend on old EAPIs, and
you've got a TODO list. (eclasses, I don't know; I don't know if
eclasses explicitly express EAPI compatibility in metadata) Once that
list is cleared, yes, you can assume there are no ebuilds with a
specified EAPI of 0. I'd presume it would have been made widely known
that new ebuilds shouldn't use the old EAPI by that point, and so
support for the deprecated EAPI level can be abandoned.

Out-of-tree ebuilds pose their own problems, but that's a matter for
the managers of the relevant overlays.

Now, for the million-dollar question: Who should do the work? My
answer would be "whoever wants it done." Whoever wants the work done
can go through their audit list and submit the relevant patches to the
maintainers. Whether that's a team of twenty people or the work of an
individual with a shell script and a lot of time on his hands, that's
where that kind of work belongs. Now, if a maintainer rejects the
patch, then the submitter can fix the patch to the maintainer's
specifications. If the maintainer rejects the patch on some principle,
that's an issue that can be raised and dealt with rationally at the
time it happens. I imagine most maintainers would welcome assistance,
especially if it means simplifying future work they may need to do.

--
:wq
 
Old 08-30-2012, 08:11 PM
Ciaran McCreesh
 
Default EAPI usage

On Thu, 30 Aug 2012 16:05:52 -0400
Michael Mol <mikemol@gmail.com> wrote:
> Compile a list of existing ebuilds which depend on old EAPIs, and
> you've got a TODO list. (eclasses, I don't know; I don't know if
> eclasses explicitly express EAPI compatibility in metadata) Once that
> list is cleared, yes, you can assume there are no ebuilds with a
> specified EAPI of 0. I'd presume it would have been made widely known
> that new ebuilds shouldn't use the old EAPI by that point, and so
> support for the deprecated EAPI level can be abandoned.

You can't uninstall a package if you don't support its EAPI.

The "remove code" benefit applies to eclasses, not package manglers.

--
Ciaran McCreesh
 
Old 08-30-2012, 09:25 PM
Rich Freeman
 
Default EAPI usage

On Thu, Aug 30, 2012 at 3:44 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> Andreas K. Huettel schrieb:
>> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>>> Could you elaborate what the reasons FOR it are (not that I don't know
>>> any, but you brought it up) since this will add work for every developer
>>> to check a) how the behavior of the new EAPI impacts the current ebuild
>>> and b) how the behvaior of inherited eclasses change depending on EAPI.
>>
>> a) Easier eclass maintenance.
>> Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler.
>> We'll raise that to 4 only soon (after fixing the remaining ebuilds in the
>> tree.)
>
> An eclass, which includes helper commands like eutils or versionator
> eclass wont benefit from it. Only specific eclasses (like your kde
> example would benefit and for those, the related team can always decide
> to bump all their packages to the wanted EAPI and then to bump the
> eclass requirement. So no need to force this on everyone else.

Agreed. I'm fine with asking maintainers to change EAPI in specific
cases where there is a specific benefit. Diego sends me bug reports
from time to time for whatever odd set of circumstances cause some
kind of problem on a tinderbox, and when I can I fix the bugs and
report upstream. The result is a better experience for all, even
beyond Gentoo. If somebody wants to drop code in qt.eclass or
whatever and my bumping EAPI makes their life easier they can always
ask nicely and I'm happy to help out. What I don't see the value in
is policies that extend the work beyond where the benefit lies.

Rich
 
Old 08-30-2012, 10:50 PM
hasufell
 
Default EAPI usage

It's very simple. People will just ignore this if they disagree and
leave any "bump to EAPI-latest already" bugs unresolved forever.
 
Old 08-30-2012, 11:58 PM
Duncan
 
Default EAPI usage

Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:

> On Thu, 30 Aug 2012 16:05:52 -0400 Michael Mol <mikemol@gmail.com>
> wrote:
>> Compile a list of existing ebuilds which depend on old EAPIs, and
>> you've got a TODO list. (eclasses, I don't know; I don't know if
>> eclasses explicitly express EAPI compatibility in metadata) Once that
>> list is cleared, yes, you can assume there are no ebuilds with a
>> specified EAPI of 0. I'd presume it would have been made widely known
>> that new ebuilds shouldn't use the old EAPI by that point, and so
>> support for the deprecated EAPI level can be abandoned.
>
> You can't uninstall a package if you don't support its EAPI.
>
> The "remove code" benefit applies to eclasses, not package manglers.

I've seen that reason given before, and it makes sense... to a point.

Would this work, tho?

In addition to the tree clean of EAPI-X to be dropped...

Some minimum time/versions (say six months) before a PM drops support for
it, on PM upgrades it starts warning about the coming drop of EAPI-X
support, giving the user a reasonable deadline (the same six months) to
upgrade or uninstall said packages as PM versions after that date will be
dropping support.

Then at a shorter deadline (say two months), start warning at each PM
invocation.

When the upgrade that will drop support appears, if any packages of now
unsupported EAPI-X remain installed, it simply dies with a warning that
upgrading isn't possible as unsupported packages remain installed,
instructing the user to upgrade or unmerge them first, before upgrading
the PM.

By this time, the tree would have been clean of EAPI-X for the longer
deadline (six months in this example), and the warning will have appeared
on PM upgrade for the same period and on every PM invocation for the
shorter period (two months here), so people doing anything close to
regular upgrades will have long since upgraded past or unmerged whatever
lagging packages they had merged.

For the people that do NOT upgrade frequently, the die before PM upgrade
will force the issue, if/when they DO decide to upgrade.

Covering the case where the troublesome packages themselves have moved on
beyond something the installed PM can handle, it's still possible to
unmerge the package temporarily, then merge it again after they upgrade.

(If thought necessary, the usual I_KNOW_WHAT_IM_DOING override could be
inserted, but in this case I think simply having them unmerge the
packages in question is the safer alternative. After all, it's only
going to hit the folks who are SO far out of date that there's no
bridging package version available, for the offending package.)

Of course there'd need to be special consideration given to critical
toolchain and system boot packages, but /that's/ nothing new.

And as has always been the case, for the /extreme/ laggards, at some
point, say two years out or whatever, simply don't support upgrading that
far any more, with a clean install from stage-3 being the recommended
alternative.

Of course an individual PM could choose to keep support for as long as
they want, but unless I'm missing something, that'd let PMs drop support
for old EAPIs if desired, with at least a reasonably sane upgrade path
for both PM devs and users.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 

Thread Tools




All times are GMT. The time now is 02:44 AM.

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