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-11-2012, 11:01 AM
Pacho Ramos
 
Default Deprecate EAPI1?

After reading previous discussion:
http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html

Looks like preventing NEW commits from using eapi1 (via repoman) could
be done without major issues. This could even being done also for eapi2
as it's close enough to eapi3, but I don't have a strong opinion about
eapi2 deprecation (personally, I try to always use latest eapi if eclass
allows me to do so).

Any thoughts on this?

Thanks
 
Old 03-11-2012, 12:28 PM
Patrick Lauer
 
Default Deprecate EAPI1?

On 03/11/12 20:01, Pacho Ramos wrote:
> After reading previous discussion:
> http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html
>
> Looks like preventing NEW commits from using eapi1 (via repoman) could
> be done without major issues. This could even being done also for eapi2
> as it's close enough to eapi3, but I don't have a strong opinion about
> eapi2 deprecation (personally, I try to always use latest eapi if eclass
> allows me to do so).
>
> Any thoughts on this?

I'd deprecate eapi2 too, we don't need 5 flavours around when we
effectively only want to support one (and eapi0 in a few places)

I wouldn't mind having a deprecation timeline for eapi3 too (now +6
months maybe?), but there's no need to rush things.
 
Old 03-11-2012, 12:52 PM
Rich Freeman
 
Default Deprecate EAPI1?

On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> I'd deprecate eapi2 too, we don't need 5 flavours around when we
> effectively only want to support one (and eapi0 in a few places)
>
> I wouldn't mind having a deprecation timeline for eapi3 too (now +6
> months maybe?), but there's no need to rush things.

Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package managers planned on supporting all the EAPIs for
quite a while longer.

I can imagine that this will lead to quite a bit of churn with
updating ebuilds and especially eclasses. If a package doesn't
require a feature in a newer EAPI, what is the point?

Why not deprecate the x86 arch while we're at it...

Rich
 
Old 03-11-2012, 12:54 PM
Samuli Suominen
 
Default Deprecate EAPI1?

On 03/11/2012 03:52 PM, Rich Freeman wrote:

On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer<patrick@gentoo.org> wrote:

I'd deprecate eapi2 too, we don't need 5 flavours around when we
effectively only want to support one (and eapi0 in a few places)

I wouldn't mind having a deprecation timeline for eapi3 too (now +6
months maybe?), but there's no need to rush things.


Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package managers planned on supporting all the EAPIs for
quite a while longer.

I can imagine that this will lead to quite a bit of churn with
updating ebuilds and especially eclasses. If a package doesn't
require a feature in a newer EAPI, what is the point?


+1, it doesn't make any sense unless the request is coming from
dev-portage@ developers (Zac namely :-) as a part of code cleanup


I still find EAPI=1 useful myself when, for example, new GNOME 3
packages gets introduced to tree and there is a need to touch EAPI=0
ebuilds just to add SLOT deps.
 
Old 03-11-2012, 12:55 PM
Ciaran McCreesh
 
Default Deprecate EAPI1?

On Sun, 11 Mar 2012 09:52:40 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> Is there really much of a benefit to this? I guess for anybody who
> runs scripts to mass-manipulate ebuilds it might be helpful, but I
> think all the package managers planned on supporting all the EAPIs for
> quite a while longer.

We have to support them indefinitely. It's not possible to uninstall a
package whose EAPI is unknown.

--
Ciaran McCreesh
 
Old 03-11-2012, 01:37 PM
Patrick Lauer
 
Default Deprecate EAPI1?

On 03/11/12 21:52, Rich Freeman wrote:
> On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> I'd deprecate eapi2 too, we don't need 5 flavours around when we
>> effectively only want to support one (and eapi0 in a few places)
>>
>> I wouldn't mind having a deprecation timeline for eapi3 too (now +6
>> months maybe?), but there's no need to rush things.
>
> Is there really much of a benefit to this?

Let me phrase it like this:
Can you list all differences between EAPI 1,2,3 and 4?

It's a lot easier for everyone involved when you don't need to care
about all the special cases (like src_prepare not running) because
you've standardized on one EAPI for support

(Legacy code can be slowly phased out or upgraded, but I don't want to
remember if I can use slot-deps or use-deps and all those "irrelevant"
details)

> I guess for anybody who
> runs scripts to mass-manipulate ebuilds it might be helpful, but I
> think all the package managers planned on supporting all the EAPIs for
> quite a while longer.

That's orthogonal to the discussion - I think the goal is to reduce the
amount of errors introduced by confusing features and making the
documentation more streamlined ("Here's the EAPI you use" instead of "if
you want to learn about eapi2 go to page 62. If you don't go to page 84")
>
> I can imagine that this will lead to quite a bit of churn with
> updating ebuilds and especially eclasses. If a package doesn't
> require a feature in a newer EAPI, what is the point?
Eclasses are up-to-date as far as I remember, and it's just *new* things
that get motivated to eapi3/4 - force-updating is silly
 
Old 03-11-2012, 02:02 PM
Thomas Sachau
 
Default Deprecate EAPI1?

Patrick Lauer schrieb:
> On 03/11/12 21:52, Rich Freeman wrote:
>> On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>> I'd deprecate eapi2 too, we don't need 5 flavours around when we
>>> effectively only want to support one (and eapi0 in a few places)
>>>
>>> I wouldn't mind having a deprecation timeline for eapi3 too (now +6
>>> months maybe?), but there's no need to rush things.
>>
>> Is there really much of a benefit to this?
>
> Let me phrase it like this:
> Can you list all differences between EAPI 1,2,3 and 4?
>
> It's a lot easier for everyone involved when you don't need to care
> about all the special cases (like src_prepare not running) because
> you've standardized on one EAPI for support
>
> (Legacy code can be slowly phased out or upgraded, but I don't want to
> remember if I can use slot-deps or use-deps and all those "irrelevant"
> details)

You dont have to. The suggested EAPI for new ebuilds is already the
latest one and you are free to use that.

On the other side, if someone wants to use some other EAPI for whatever
reason, why should he not be allowed to do so? He has to maintain it and
any EAPI changes.

Additionally, an ebuild with a lower EAPI may already exist for a long
time, this would force the dev to convert it to a newer EAPI to be
allowed to add it to the main tree, also the existing ebuild works just
fine.

--

Thomas Sachau
Gentoo Linux Developer
 
Old 03-11-2012, 02:49 PM
Ciaran McCreesh
 
Default Deprecate EAPI1?

On Sun, 11 Mar 2012 16:14:33 +0100
Ch*-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> Ciaran McCreesh schrieb:
> >> Is there really much of a benefit to this? I guess for anybody who
> >> runs scripts to mass-manipulate ebuilds it might be helpful, but I
> >> think all the package managers planned on supporting all the EAPIs
> >> for quite a while longer.
> > We have to support them indefinitely. It's not possible to
> > uninstall a package whose EAPI is unknown.
> >
>
> Would it be feasible to do a pkg_pretend() check and refuse
> install/upgrade if packages with unsupported EAPI are detected?

Uhm. I think your question doesn't make any sense, but maybe I'm just
not understanding it. Rephrase please.

--
Ciaran McCreesh
 
Old 03-11-2012, 03:27 PM
Ciaran McCreesh
 
Default Deprecate EAPI1?

On Sun, 11 Mar 2012 17:18:45 +0100
Ch*-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> Assume a new version 13.37 of your package manager drops EAPI=1
> support. So package-manager-13.37.ebuild checks in pkg_pretend() if
> any EAPI=1 package is installed on the system. If yes, then it
> aborts, telling the user to get rid of the package first.

Oh, now I get it. There are two issues there...

First, doing that is going to screw things up for users who have two
package managers installed, unless you make every package mangler's
package aware of every package mangler.

Second, there's not a way of getting the information you need to figure
that out using current EAPIs.

It's also not really worth it at the moment. There aren't any major
architectural changes between EAPIs just now, so removing support for
an EAPI won't allow any majorly nasty code to be removed from a package
manager. It might be worth revisiting this if we ever switch to EAPIs
that allow us to kill off VDB, for example.

--
Ciaran McCreesh
 
Old 03-11-2012, 03:52 PM
Ciaran McCreesh
 
Default Deprecate EAPI1?

On Sun, 11 Mar 2012 17:46:05 +0100
Ch*-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> That I suspected, that's why I asked about feasibility.
> "grep 1 $(portageq vdb_path)/*/*/EAPI && die" might work for portage
> and its current VDB layout.

vdb_path is one of those things that really really needs to die...
Being able to replace VDB with something that doesn't suck is one of
the places where being able to kill off old code would actually matter.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 05:09 PM.

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