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-31-2012, 12:38 AM
Rich Freeman
 
Default EAPI usage

On Thu, Aug 30, 2012 at 7:58 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:
> 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.

I actually don't have a problem with this. If there were a
coordinated effort to completely deprecate an EAPI and the PM teams
vouched that it would make their life easier, I'd be happy to be a
part of a concerted effort to bump everything to where it needs to be.
If we made the transition long then it would be mostly transparent to
users. If they had some odd package still installed with an old EAPI
they could always re-install it to clean up the installed package
database.

My main concern is doing bumps all the time just for their own sake.

Rich
 
Old 08-31-2012, 03:33 AM
Duncan
 
Default EAPI usage

Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted:

> My main concern is doing bumps all the time just for their own sake.

Yes. That's why I didn't tackle that side at all. But I've seen the
"PM's can never drop support for an EAPI once adopted" thing before, and
while there's quite a possibility I'm missing something as I'm no PM
expert, it does seem to me that rings hollow; that an EAPI drop COULD be
done, without too much disrupting either users or devs (PM or otherwise).

But as the experts say otherwise, there probably /is/ something I'm
missing, which is why I asked.

Meanwhile, I'll definitely allow that there's often a big chasm between
"possible" and "worth the trouble", too, and it's quite within the realm
of reason that it's simply "not worth the trouble" at this point, even if
very much possible, and even likely worth the trouble once we get upto
say 10 EAPIs or some such.

Meanwhile(2), I (cautiously) support the idea I've seen before of
deprecating and gradually removing at least EAPI-1, and probably 2 and 3
as well over time. People /have/ pointed out that core system packages,
toolchain, etc, may well need to stay at EAPI-0 virtually "forever".
That's the exception I mentioned with EAPI-0 thus being an exception as
well, thus the focus on 1-3. But once 1-3 are out of the tree for a
sufficient period, I really /don't/ see why the method I described can't
be used to drop their support from the PMs, as well, and expect that
regardless of whether it's worth tackling as a project starting today, at
some point, it'll be worth doing.

OTOH, I can see someone, possibly concerned about the historical
implications (so "gentoo historians" at least, can try long deprecated
ebuilds and see how they work), might wish to maintain support for every
EAPI "forever". But I don't believe it should be mandatory, and in
practice, I'd venture that due to simple code rot once there haven't been
any packages of a particular EAPI in the tree or in wide circulation for
awhile, even if support /does/ officially continue, it'll likely be
broken if anyone tries to use it, say five years or a decade later. Once
that starts being a major concern, why /not/ just dump it. The
historians can go find an old stage tarball with an old PM that supported
the EAPIs they're interested in, if it comes to that.

--
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
 
Old 08-31-2012, 09:03 AM
"Andreas K. Huettel"
 
Default EAPI usage

Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
> On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber <johu@gentoo.org> wrote:
> >> scarabeus suggested the change "dev should use latest eapi when bumping"
> >> to "dev must use latest eapi when bumping if not forbidden by eclasses".
> >> He was asked to bring it up on the mailing lists, to get a better
> >> definition of when what EAPI should be used.
> >
> > I raised the issue through scarabeus, as in my opinion there is no reason
> > to not use latest EAPI. So please discuss.
>
> I can't say I'm a big fan of this. This requires forcing changes to
> ebuilds that offer no actual benefit to either the maintainer or the
> end-users (changes that actually have some benefit to either are
> likely to be made anyway). The PM maintainers have chimed in that
> there is no benefit to PM maintenance from this change.
>
> So, I can't really see what the upside of such a policy is.
>

<rant>
Let's say, we as in Gentoo decide that we're completely sick of keeping all
that old code out there adjusted to newer and newer gcc versions that are more
and more critical towards minor details of the c++ 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.

Well, newer gcc versions might have some very minor marginal advantages, but
they require that we mess with code that has worked for ages. They require
that we actually give some thought on the evolution of the language semantics
or nag upstream, but we can't really be bothered with that because of limited
time. Also, keeping gcc-4.5 will always (trivially) keep us backward
compatibility... much more important than forward compatibility, should
porting to a much never future version ever become necessary.

For a real world analogy, serious quakes happen only once a century... why
should we even bother with improving building codes? I mean, at some point in
the future things will fall apart anyway. Better dont shake anything in
between.
</rant>

Sorry but I could not really resist... please take it with a grain of salt.
However, seriously, ...

Give me one non-trivial ebuild where you can absolutely guarantee that a bump
from EAPI=0 to EAPI=4 will not enable any improvements (in readability,
failsafe behaviour and code size for example).

Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
we'll have succeeded in generating an unmaintainable mess (tm). It will not be
any fun to look up things in PMS anew everytime you edit something. (Was the
prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in
pkg_preinst?) This problem could however also be solved by selectively phasing
out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

Cheers,
Andreas

--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 08-31-2012, 09:11 AM
Fabian Groffen
 
Default EAPI usage

On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote:
> any fun to look up things in PMS anew everytime you edit something. (Was the
> prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in
> pkg_preinst?) This problem could however also be solved by selectively phasing
> out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

I guess you meant 1 and 2.


--
Fabian Groffen
Gentoo on a different level
 
Old 08-31-2012, 09:27 AM
"Andreas K. Huettel"
 
Default EAPI usage

Am Freitag, 31. August 2012, 11:11:37 schrieb Fabian Groffen:
> On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote:
> > any fun to look up things in PMS anew everytime you edit something. (Was
> > the prayer to Paludis only required in EAPI=7 in src_prepare or in
> > EAPI=8 in pkg_preinst?) This problem could however also be solved by
> > selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3
> > asap).
>
> I guess you meant 1 and 2.

Actually I dont care... but 2 could certainly go faster than 3, true.

--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 08-31-2012, 09:33 AM
Johannes Huber
 
Default EAPI usage

Am Freitag, 31. August 2012, 11:03:06 schrieb Andreas K. Huettel:
> Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
> > On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber <johu@gentoo.org> wrote:
> > >> scarabeus suggested the change "dev should use latest eapi when
> > >> bumping"
> > >> to "dev must use latest eapi when bumping if not forbidden by
> > >> eclasses".
> > >> He was asked to bring it up on the mailing lists, to get a better
> > >> definition of when what EAPI should be used.
> > >
> > > I raised the issue through scarabeus, as in my opinion there is no
> > > reason
> > > to not use latest EAPI. So please discuss.
> >
> > I can't say I'm a big fan of this. This requires forcing changes to
> > ebuilds that offer no actual benefit to either the maintainer or the
> > end-users (changes that actually have some benefit to either are
> > likely to be made anyway). The PM maintainers have chimed in that
> > there is no benefit to PM maintenance from this change.
> >
> > So, I can't really see what the upside of such a policy is.
>
> <rant>
> Let's say, we as in Gentoo decide that we're completely sick of keeping all
> that old code out there adjusted to newer and newer gcc versions that are
> more and more critical towards minor details of the c++ 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.
>
> Well, newer gcc versions might have some very minor marginal advantages, but
> they require that we mess with code that has worked for ages. They require
> that we actually give some thought on the evolution of the language
> semantics or nag upstream, but we can't really be bothered with that
> because of limited time. Also, keeping gcc-4.5 will always (trivially) keep
> us backward compatibility... much more important than forward
> compatibility, should porting to a much never future version ever become
> necessary.
>
> For a real world analogy, serious quakes happen only once a century... why
> should we even bother with improving building codes? I mean, at some point
> in the future things will fall apart anyway. Better dont shake anything in
> between.
> </rant>
>
> Sorry but I could not really resist... please take it with a grain of salt.
> However, seriously, ...
>
> Give me one non-trivial ebuild where you can absolutely guarantee that a
> bump from EAPI=0 to EAPI=4 will not enable any improvements (in
> readability, failsafe behaviour and code size for example).
>
> Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
> we'll have succeeded in generating an unmaintainable mess (tm). It will not
> be any fun to look up things in PMS anew everytime you edit something. (Was
> the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8
> in pkg_preinst?) This problem could however also be solved by selectively
> phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

Words of wisdom, nothing to add.

Greetings.

> Cheers,
> Andreas

Cheers,
--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD
 
Old 08-31-2012, 12:14 PM
Rich Freeman
 
Default EAPI usage

On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> <rant>
> Let's say, we as in Gentoo decide that we're completely sick of keeping all
> that old code out there adjusted to newer and newer gcc versions that are more
> and more critical towards minor details of the c++ 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.

>
> Give me one non-trivial ebuild where you can absolutely guarantee that a bump
> from EAPI=0 to EAPI=4 will not enable any improvements (in readability,
> failsafe behaviour and code size for example).

Suppose for the sake of argument that no such ebuild exists. I still
maintain that there is little benefit from forcing an EAPI bump on new
ebuilds.

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.
The only reason you'd need a policy is if I as a maintainer figured
that bumping the EAPI was more hassle than whatever benefits I get
down the road from all those improvements.

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.
So, while all those benefits you named are "enabled" few would
actually be realized.

>
> Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
> we'll have succeeded in generating an unmaintainable mess (tm). It will not be
> any fun to look up things in PMS anew everytime you edit something.

I suspect that most devs just edit things that they maintain, and that
means that they can control how many EAPIs are in use in those
ebuilds. Again, devs already have incentive to make their own lives
earlier - we don't need to turn that into policy.

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.

Rich
 
Old 08-31-2012, 02:23 PM
Zac Medico
 
Default EAPI usage

On 08/30/2012 08:33 PM, Duncan wrote:
> Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted:
>
>> My main concern is doing bumps all the time just for their own sake.
>
> Yes. That's why I didn't tackle that side at all. But I've seen the
> "PM's can never drop support for an EAPI once adopted" thing before, and
> while there's quite a possibility I'm missing something as I'm no PM
> expert, it does seem to me that rings hollow; that an EAPI drop COULD be
> done, without too much disrupting either users or devs (PM or otherwise).
>
> But as the experts say otherwise, there probably /is/ something I'm
> missing, which is why I asked.

It would be a bad idea to remove support for *uninstalling* an ebuild
with a given EAPI, since any given system that the PM encounters could
potentially have ebuilds with any old EAPI installed. OTOH, removing
support for *installing* a given EAPI is quite feasible.

In Portage, we occasionally deprecate EAPIs that only existed for the
purpose of testing. Once an EAPI is deprecated, ebuilds using that EAPI
can no longer be installed, but they can still be uninstalled (including
execution of pkg_prerm/pkg_postrm phases).

That said, deprecation of official EAPIs such as EAPI 0, 1, and 2 would
not lead to much code being removed, because the later EAPIs share so
much code with them. So, deprecating official EAPIs provides little or
no benefit in terms of code maintenance.
--
Thanks,
Zac
 
Old 08-31-2012, 02:49 PM
Ciaran McCreesh
 
Default EAPI usage

On Thu, 30 Aug 2012 23:58:00 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> 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.

It's irrelevant: the amount of package mangler code to be saved by
removing old EAPIs is so small it's not worth discussing. Most EAPI
changes so far have either been additions or very simple behaviour
tweaks, not removals of annoying things.

There are things we might change in future EAPIs that will in the very
long term make this discussion worthwhile. If we get rid of VDB access
or unconstrained env saving, *then* it might be worth having this
discussion.

--
Ciaran McCreesh
 
Old 09-02-2012, 12:16 AM
Brian Harring
 
Default EAPI usage

On Fri, Aug 31, 2012 at 03:49:43PM +0100, Ciaran McCreesh wrote:
> On Thu, 30 Aug 2012 23:58:00 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> > 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.
>
> It's irrelevant: the amount of package mangler code to be saved by
> removing old EAPIs is so small it's not worth discussing. Most EAPI
> changes so far have either been additions or very simple behaviour
> tweaks, not removals of annoying things.

Just seconding this statement; no PM author has stated "maintaining
EAPIs is an undue burden"- it's come everytime from folks who don't
/actually do any PM code/.

So please stop telling us what is, and isn't a burden in our code.


> There are things we might change in future EAPIs that will in the very
> long term make this discussion worthwhile. If we get rid of VDB access
> or unconstrained env saving, *then* it might be worth having this
> discussion.

Realistically even then, that's just swivelling vars/functions exposed
to the ebuild env- it would require the vast majority of ebuilds
migrating to EAPI versions that hide VDB access for this to be worth
discussing (else due to backwards compat, it's a pointless
discussion).


Either way, there's no reason to require devs use the latest EAPI;
they migrate at their own pace as they need to, which is fine. Case
in point, check gentoo-x86 eapi usage:

repository '/var/db/repos/gentoo':
eapi: '4' 13523 pkgs found, 42.58% of the repository
eapi: '0' 8171 pkgs found, 25.73% of the repository
eapi: '2' 5246 pkgs found, 16.52% of the repository
eapi: '3' 4297 pkgs found, 13.53% of the repository
eapi: '1' 520 pkgs found, 1.64% of the repository

0 is still in heavy usage since a lot of ebuilds don't need the newer
EAPI functionality; 1 is mostly dead since the only gain of it (in
comparison to 0) was slot deps, 2 had used use deps thus those same
folk migrated to 2 (since if you need slot deps, it's semi likely you
need use deps).

As for 3... that was prefix and xz support. No reason to use it in
comparison to 4 frankly.

Personally, I don't have any problems if gentoo were to mandate that
EAPI1 shouldn't be used for new ebuilds in gentoo-x86, eapi2 instead.
That sort of standard would make sense.

~harring
 

Thread Tools




All times are GMT. The time now is 02:06 PM.

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