[gentoo-dev] Deprecate EAPI1?

[gentoo-dev] Deprecate EAPI1?

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Patrick Lauer]

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.

Re: [gentoo-dev] Deprecate EAPI1?

[Rich Freeman]

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

Re: [gentoo-dev] Deprecate EAPI1?

[Samuli Suominen]

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.

Re: [gentoo-dev] Deprecate EAPI1?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Patrick Lauer]

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

Re: [gentoo-dev] Deprecate EAPI1?

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Chí-Thanh Christopher Nguyễn]

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?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Deprecate EAPI1?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
> 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.
>

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.

That way, the situation where the package manager does not know how to
uninstall a package is avoided.

Note that I do not suggest that this be done, I only show that it can be
possible to drop old EAPI support.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Deprecate EAPI1?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
> 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.

As long as the package managers are installed through ebuilds, they
should observe each other's pkg_pretend()

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

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.
One problem that remains with this approach is what happens if an EAPI=1
package is in the list of packages to be merged along with the new
package manager.

> 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.

Yes, tommy already told me on IRC that there is no incentive for package
managers to drop EAPI support at this time.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Deprecate EAPI1?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Rich Freeman]

On Sun, Mar 11, 2012 at 12:18 PM, 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.
>
> That way, the situation where the package manager does not know how to
> uninstall a package is avoided.

I take it that removing a package without using a package manager is
left as an exercise to the reader?

Rich

Re: [gentoo-dev] Deprecate EAPI1?

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> On Sun, Mar 11, 2012 at 12:18 PM, 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.
>>
>> That way, the situation where the package manager does not know how to
>> uninstall a package is avoided.
> I take it that removing a package without using a package manager is
> left as an exercise to the reader?

The user will have to remove the package using his current, EAPI=1
capable package manager.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Deprecate EAPI1?

[Francesco Riosa]

2012/3/11 Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> 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.

probably not needed in practice, some random toughts follow.

upgrade a gentoo system older than three years is nearly impossible,
even update small part of it can be a major problem. Solution being
install from scratch in a new partition or overwrite with a stage 3
and abuse "qfile -o".

Hopefully situation will change in the future, and we will able to
eix-sync and upgrade all of gentoo or only part of it.

At the moment tough the ability to ununstall a package from year
2008/2009 is moot, the system is screwed anyway.

except for the possible existance of packages which have not been
updated in 3/4 years (do they exist?) it's possible for all package
mangler (tm) to consider pre 2009 stuff as forgotten.

regards,
Francesco

Re: [gentoo-dev] Deprecate EAPI1?

[Richard Yao]

These must be maintained indefinitely to provide an upgrade path for
older Gentoo Linux installations. It is rare, but people do upgrade
old installs from time to time. Without some EAPI=1 packages, there is
no path for people to use to upgrade.

On Sun, Mar 11, 2012 at 8:01 AM, Pacho Ramos <pacho@gentoo.org> 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?
>
> Thanks

Re: [gentoo-dev] Deprecate EAPI1?

[Francesco Riosa]

top-posting me too to avoid more confusion, sorry

Se my other reply to this thread, upgrading in place an old gentoo
install is nearly impossible, it's so bad that glibc breakage can
occour, that require a knowledge of the system so high that everything
else become nuances of a vague problem.
Tell everyone that it's not possible to upgrade a 2009 system id more
honest and free everybody from forever compatibility slavery.

To be able to upgrade a gentoo installation as old as five years is
interesting and valuable but require an effort that has yet to be
made.

P.S. I'm neutral about EAPI 1 deprecation, just stating that forever
support is a chimera right now

2012/3/11 Richard Yao <ryao@cs.stonybrook.edu>:
> These must be maintained indefinitely to provide an upgrade path for
> older Gentoo Linux installations. It is rare, but people do upgrade
> old installs from time to time. Without some EAPI=1 packages, there is
> no path for people to use to upgrade.
>
> On Sun, Mar 11, 2012 at 8:01 AM, Pacho Ramos <pacho@gentoo.org> 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?
>>
>> Thanks
>

Re: [gentoo-dev] Deprecate EAPI1?

[Chí-Thanh Christopher Nguyễn]

Richard Yao schrieb:
> These must be maintained indefinitely to provide an upgrade path for
> older Gentoo Linux installations. It is rare, but people do upgrade
> old installs from time to time. Without some EAPI=1 packages, there is
> no path for people to use to upgrade.

The clean upgrade path from 2008.0 (still popular with some hosting
companies) has already been destroyed with the removal of
python-2.6.5-r3 a couple of months ago.
It is up to the maintainers whether they want to invest time and energy
into the old packages, and usually they don't. And it is indeed
questionable whether users who update less than once every 6 months are
worth this investment. (I tend to say yes, but that may just be because
many come to #gentoo IRC with the resulting problems.)



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Deprecate EAPI1?

[Rich Freeman]

On Sun, Mar 11, 2012 at 8:15 PM, Francesco Riosa <vivo75@gmail.com> wrote:
> To be able to upgrade a gentoo installation as old as five years is
> interesting and valuable but require an effort that has yet to be
> made.

I suspect it shouldn't be difficult IF you have access to a binary
package respository for the system set.  Then you can do an emerge -K
system and get all your core packages updated.

In theory you should be able to install a gentoo stage3 in a chroot
and do a quickpkg @system to generate such a repository.

I'm open to comments as to why this wouldn't work, but it would seem
to be the easiest solution to me.

Of course, this won't get you whatever CFLAGS/USE settings you prefer
- but once you have a working updated system set you could always do
an emerge -e system to rebuild them with your own settings.

Rich

Re: [gentoo-dev] Deprecate EAPI1?

[Brian Harring]

On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n 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?

The question should be "is it worth doing it", rather than "can we 
hack out something".

As Ciaran said, PM's are going to be supporting EAPI1 indefinitely- 
it's zero cost to do so at this point.  Thus doing what you're 
proposing doesn't gain us anything but complexity.

If people want to enforce the eapi1 is no longer used in the gentoo 
repo, that's fine- we stick a list of acceptable EAPI's into 
its layout.conf.

If you want to block EAPI1 from being further used, go that route; at 
least for pkgcore (and presumably paludis, likely portage), ripping 
out EAPI1 is unlikely to occur anything this side of 2015.

~brian

Re: [gentoo-dev] Deprecate EAPI1?

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

El dom, 11-03-2012 a las 13:01 +0100, Pacho Ramos escribió:
> 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

Well, the reasons for me preferring to not allow *new* ebuilds to use
eapi1 is to try to move to use things like, for example,
src_prepare/src_configure phases. I guess that phases were included for
some "technical" reasons and, then, I think we should try to use them if
possible install of still adding NEW ebuilds using old eapi0/1 way of
doing things

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Zac Medico]

On 03/11/2012 05:49 PM, Brian Harring wrote:
> If people want to enforce the eapi1 is no longer used in the gentoo 
> repo, that's fine- we stick a list of acceptable EAPI's into 
> its layout.conf.

That sounds pretty reasonable, although I think a deprecation warning
would be more appropriate that an outright ban. A deprecation warning
should be sufficient to send the intended message, without placing an
unnecessary burden on people doing simple version bumps or adding
ebuilds that are already well tested though they happen to use an older
EAPI.
-- 
Thanks,
Zac

Re: [gentoo-dev] Deprecate EAPI1?

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1743 bytes --]

On Monday 12 of March 2012 01:49:35 Brian Harring wrote:
> On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n 
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?
> 
> The question should be "is it worth doing it", rather than "can we
> hack out something".
> 
> As Ciaran said, PM's are going to be supporting EAPI1 indefinitely

In principle, it's actually entirely possible for any PM to start supporting 
exclusively completely API and ABI-breaking EAPI.

There's always the problem with self-upgrading software as it needs to somehow 
predict (and limit) its development to keep upgrade paths.
We have this exact problem where I work (with updating basestation SW) and 
some solution for this software is to stop being self-upgrading.

With external upgrade tool (which would rsync package tree do any 
vdb/metadata-magic needed) one could replace current PM with latest, API/ABI-
incompatible PM version.

Now, it may not really make sense for PM as upgrade process of PM itself isn't 
any different from upgrade process of any other package, still it would allow 
any API/ABI-breaking ebuild format changes to be introduced if we really need 
them so badly.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Deprecate EAPI1?

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

El mar, 13-03-2012 a las 11:52 -0700, Zac Medico escribió:
> On 03/11/2012 05:49 PM, Brian Harring wrote:
> > If people want to enforce the eapi1 is no longer used in the gentoo 
> > repo, that's fine- we stick a list of acceptable EAPI's into 
> > its layout.conf.
> 
> That sounds pretty reasonable, although I think a deprecation warning
> would be more appropriate that an outright ban. A deprecation warning
> should be sufficient to send the intended message, without placing an
> unnecessary burden on people doing simple version bumps or adding
> ebuilds that are already well tested though they happen to use an older
> EAPI.

I fully agree with this approach 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]