[gentoo-dev] Deprecate EAPIs 0 and 1?

[gentoo-dev] Deprecate EAPIs 0 and 1?

[Ulrich Mueller]

Hi,

after approval of EAPI 4, there are now 5 different EAPIs available,
and it's hard to remember what features are offered by which EAPI.

So maybe it's about time that we deprecate EAPIs 0 and 1 for new
ebuilds. As a first step, a warning could be added to repoman that
would be triggered whenever a new ebuild with an EAPI less than 2 is
committed.

At a later time, the warning could be changed to an error. When most
of the tree has been updated to EAPI 2 or newer, we could also think
about actively converting the remaining ebuilds. (Currently this
doesn't look feasible though, as about half of the tree is still at
EAPI=0. [1])

Opinions?

Ulrich

[1] <http://blogs.gentoo.org/alexxy/2010/11/06/some-interesting-stats-about-gentoo-portage-tree/>

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Petteri Räty]

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

On 12/31/2010 01:02 PM, Ulrich Mueller wrote:
> Hi,
> 
> after approval of EAPI 4, there are now 5 different EAPIs available,
> and it's hard to remember what features are offered by which EAPI.
> 
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.
> 

First we need to be sure that all relevant eclasses support upgrading to
EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some
eclasses are too. But I do second the idea of trying to limit the set of
active EAPIs in the tree. Please open a repoman bug if there are no
objections.

> At a later time, the warning could be changed to an error. When most
> of the tree has been updated to EAPI 2 or newer, we could also think
> about actively converting the remaining ebuilds. (Currently this
> doesn't look feasible though, as about half of the tree is still at
> EAPI=0. [1])
> 

EAPI 0 might stick around for quite a while but for example deprecating
EAPI 1 shouldn't be as hard.

Regards,
Petteri


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

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Zac Medico]

On 12/31/2010 03:13 AM, Petteri Räty wrote:
> First we need to be sure that all relevant eclasses support upgrading to
> EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some
> eclasses are too.

As an example of things to look for, I've noticed that migration to EAPI
2 or later of any ebuild that inherits linux-mod_src_compile() will
trigger the following QA Notice from econf:

  QA Notice: econf called in src_compile instead of src_configure
-- 
Thanks,
Zac

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

["Paweł Hajdan, Jr."]

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

On 12/31/10 12:13 PM, Petteri Räty wrote:
> EAPI 0 might stick around for quite a while but for example deprecating
> EAPI 1 shouldn't be as hard.

That seems also to be a safe first step. EAPI-1 ebuilds were at least
written with EAPIs in mind. That's obviously not true for EAPI-0.

We could even deprecate EAPI-2 in favor of EAPI-3, hmmm....

I think a repoman non-fatal warning would be fine. If we have a warning
about forcing -j1, we can surely have one about ancient EAPIs.

Paweł Hajdan, Jr.

P.S. I'm excited to see the progress with PMS and new EAPIs being more
and more convenient and addressing frequent annoyances or deficiencies!


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

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Donnie Berkholz]

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

On 16:46 Fri 31 Dec     , "Paweł Hajdan, Jr." wrote:
> On 12/31/10 12:13 PM, Petteri Räty wrote:
> > EAPI 0 might stick around for quite a while but for example deprecating
> > EAPI 1 shouldn't be as hard.
> 
> That seems also to be a safe first step. EAPI-1 ebuilds were at least
> written with EAPIs in mind. That's obviously not true for EAPI-0.
> 
> We could even deprecate EAPI-2 in favor of EAPI-3, hmmm....
> 
> I think a repoman non-fatal warning would be fine. If we have a warning
> about forcing -j1, we can surely have one about ancient EAPIs.

I'm in favor of documenting things such that the latest EAPI is the 
standard and others are backwards diffs based on it, shifted to 
appendices or somewhere out of the way. This will encourage people to 
easily use the latest developments rather than trying to build up a 
mental stack of added and removed features across multiple levels.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

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

[gentoo-dev] Re: Deprecate EAPIs 0 and 1?

[Christian Faulhammer]

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

Hi,

Donnie Berkholz <dberkholz@gentoo.org>:
> rather than trying to build up a 
> mental stack of added and removed features across multiple levels.

 I always recommend the Reference Card which fits on one page and sums
up most features of the EAPIs (found as the last two pages of PMS).

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

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

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Patrick Lauer]

On 12/31/10 12:02, Ulrich Mueller wrote:
> Hi,
> 
> after approval of EAPI 4, there are now 5 different EAPIs available,
> and it's hard to remember what features are offered by which EAPI.
> 
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

That's a good idea.
As long as there's a clean upgrade path from eapi0 left I'm all for it
(and that is fragile - for example bash-completion has no eapi0 versions
left, so currently it's really ugly to upgrade portage on an old install)
> 
> At a later time, the warning could be changed to an error. When most
> of the tree has been updated to EAPI 2 or newer, we could also think
> about actively converting the remaining ebuilds. (Currently this
> doesn't look feasible though, as about half of the tree is still at
> EAPI=0. [1])

Since there's currently no need many ebuilds have never been upgraded.
If people started actively working on it we could get that done in a
short timeframe - but then I wonder if it's worth the effort.

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Enrico Weigelt]

* Ulrich Mueller <ulm@gentoo.org> schrieb:
> Hi,
> 
> after approval of EAPI 4, there are now 5 different EAPIs available,
> and it's hard to remember what features are offered by which EAPI.
> 
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

Is there a way to scan automatically for ebuilds with older EAPIs
w/o actually running emerge ? Is grep'ing sufficient ?

Just hacked up a little scan script ... see attachement.

> At a later time, the warning could be changed to an error. When most
> of the tree has been updated to EAPI 2 or newer, we could also think
> about actively converting the remaining ebuilds. (Currently this
> doesn't look feasible though, as about half of the tree is still at
> EAPI=0. [1])

IMHO, when an EAPI is declared depcreated, new or changed ebuilds
should not use it anymore. Deprecation should not happen as long
as base packages still use it.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Enrico Weigelt]

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

* Enrico Weigelt <weigelt@metux.de> schrieb:

Sorry, forgot the attachement ;-o


-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

[-- Attachment #2: scan_deprecated_eapi --]
[-- Type: text/plain, Size: 904 bytes --]

#!/bin/bash

TREE=/usr/portage

warn_eapi_missing() {
    echo "$1: missing EAPI= line"
    true
}

warn_eapi_unquoted() {
    echo "$1: EAPI= line not quoted"
    true
}

warn_eapi_deprecated() {
    echo "$1: EAPI $2 deprecated"
    true
}

check_eapi() {
    while read f ; do
	if ! grep "EAPI=" $f >/dev/null ; then
		warn_eapi_missing "$f"
	elif ! grep "EAPI=\"" $f >/dev/null ; then
		warn_eapi_unquoted "$f"
	elif grep -E "EAPI\=(0|\"0\")" $f >/dev/null; then
		warn_eapi_deprecated "$f" 0
	elif grep -e "EAPI\=(1|\"1\")" $f >/dev/null; then
		warn_eapi_deprecated "$f" 1
#	elif grep -E "EAPI\=(2|\"2\")" $f >/dev/null; then
#		warn_eapi_deprecated "$f" 2
#	elif grep -E "EAPI\=(3|\"3\")" $f >/dev/null; then
#		warn_eapi_deprecated "$f" 3
#	elif grep -E "EAPI\=(4|\"4\")" $f >/dev/null; then
#		warn_eapi_deprecated "$f" 4
	else
	    true
	fi
    done
}

find $TREE -name "*.ebuild" | check_eapi

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Brian Harring]

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

On Fri, Dec 31, 2010 at 03:57:21PM +0100, Enrico Weigelt wrote:
> * Enrico Weigelt <weigelt@metux.de> schrieb:
> 
> Sorry, forgot the attachement ;-o

This doesn't pick up eclasses, fails on EAPI='1', and generally, isn't 
the best way- use proper tools please, they exist for a reason.

Quick scan of the tree via `pinspect eapi_usage`, the percentile is
  eapi: '0' 13934 pkgs found, 50.43% of the repository
  eapi: '2' 8679 pkgs found, 31.41% of the repository
  eapi: '3' 4432 pkgs found, 16.04% of the repository
  eapi: '1' 583 pkgs found, 2.11% of the repository

Considering eapi1 basically just added slot deps... honestly I'd 
deprecate it in favor of 2.

If you want a breakdown of the eapi per cpv, use
pquery --raw --repo /path/to/your/rsync --all --attr eapi

~harring

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

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Rémi Cardona]

Le 31/12/2010 17:04, Brian Harring a écrit :
> Quick scan of the tree via `pinspect eapi_usage`, the percentile is
>   eapi: '0' 13934 pkgs found, 50.43% of the repository
>   eapi: '2' 8679 pkgs found, 31.41% of the repository
>   eapi: '3' 4432 pkgs found, 16.04% of the repository
>   eapi: '1' 583 pkgs found, 2.11% of the repository

Based on those stats, I would definitely deprecated EAPI 1 since it's
almost unused, and EAPI 2 since its behavior is really close to EAPI 3.

As others have mentioned, only for _new_ ebuilds.

My 2¢,

Rémi

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Mike Frysinger]

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

On Friday, December 31, 2010 06:02:32 Ulrich Mueller wrote:
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

personally, i dont see a problem here.  what actual burden is there for 
continuing supporting EAPI 0/1 ?  i dont think we should go around deprecating 
things for the pure fun of it.
-mike

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

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Rich Freeman]

On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>
> personally, i dont see a problem here.  what actual burden is there for
> continuing supporting EAPI 0/1 ?  i dont think we should go around deprecating
> things for the pure fun of it.
> -mike
>

I tend to agree, unless of course the maintainers of the various
package managers chime in and say that some aspect of some particular
EAPI requires them to maintain a lot of legacy code.  Then I'd be all
for dropping some.

However, with upwards of 70%+ of the tree being pre-EAPI-3, do we
really want to go around tweaking all those ebuilds just so that they
work exactly like they already work (if we don't mess anything up)?
I'm sure lots of packages are maintainer-needed, so are we going to do
a massive removal of otherwise-working packages just because of their
EAPI (I"m fine with cleaning broken packages, but why touch working
ones)?

Sure, the new EAPIs are nice, and I'm sure that devs creating new
ebuilds will follow whatever is in the devmanual (which obviously
would only reference the new way of doing things) so over time things
will take care of themselves.  Why force a change?

Again, if this is causing the package manager / repoman / etc
maintainers problems, then I'm fine with simplifying the landscape...

Rich

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Chris Richards]

On 12/31/2010 03:38 PM, Rich Freeman wrote:
> On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysinger<vapier@gentoo.org>  wrote:
>> personally, i dont see a problem here.  what actual burden is there for
>> continuing supporting EAPI 0/1 ?  i dont think we should go around deprecating
>> things for the pure fun of it.
>> -mike
>>
> I tend to agree, unless of course the maintainers of the various
> package managers chime in and say that some aspect of some particular
> EAPI requires them to maintain a lot of legacy code.  Then I'd be all
> for dropping some.

I'm not a gentoo dev, but I tend to agree here.

"If it ain't broke, don't fix it."

Later,
Gizmo

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Jeroen Roovers]

On Fri, 31 Dec 2010 12:02:32 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

I don't see a reason to deprecate an EAPI, unless you are out to stop a
specific feature from being used that was introduced in a later EAPI
and breaks the earlier EAPI. Those ebuilds should be converted or
otherwise taken care of, but it still wouldn't deprecate the older
EAPI as a whole.


     jer

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Ulrich Mueller]

>>>>> On Fri, 31 Dec 2010, Jeroen Roovers wrote:

> I don't see a reason to deprecate an EAPI, unless you are out to
> stop a specific feature from being used that was introduced in a
> later EAPI and breaks the earlier EAPI. Those ebuilds should be
> converted or otherwise taken care of, but it still wouldn't
> deprecate the older EAPI as a whole.

The package manager has to support all EAPIs indefinitely. And it also
doesn't make sense to convert existing ebuilds when half of the tree
is still at EAPI 0.

The suggestion is that EAPI >= 2 should be used for _new_ ebuilds.

And yes, the old EAPIs are a burden. For example, changing reverse
dependencies if USE dependencies are needed. It's no fun if half of
the affected ebuilds have to be changed from EAPI 0 to EAPI 2 in such
a case.

Ulrich

[gentoo-dev] Re: Deprecate EAPIs 0 and 1?

[Ryan Hill]

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

On Fri, 31 Dec 2010 12:02:32 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> Opinions?

I don't mind a warning, but I'll tell you right now there is no way I'm
using anything other than EAPI 0 for toolchain packages.  Mike might
disagree but I don't think anyone feels like rewriting and auditing
toolchain.eclass for zero benefit.

I thought there was a consensus that we wouldn't use anything other than
EAPI 0 for @system packages, but it appears python ignored that and others
followed suit.

EAPI 1 I could live without.  But I think EAPI 0, being the base on which
all other EAPIs are defined, needs to stick around indefinitely.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Deprecate EAPIs 0 and 1?

[Jeroen Roovers]

On Fri, 31 Dec 2010 18:34:03 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> I thought there was a consensus that we wouldn't use anything other
> than EAPI 0 for @system packages, but it appears python ignored that
> and others followed suit.

Oh $deity yeah.


     jer

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31-12-2010 10:02, Ulrich Mueller wrote:
> Hi,
> 
> after approval of EAPI 4, there are now 5 different EAPIs available,
> and it's hard to remember what features are offered by which EAPI.
> 
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

I agree that having too many EAPI versions around can only lead to
confusion. Furthermore, it can require extra work from developers to
ensure compatibility for ebuilds and more importantly eclasses.
Instead of deprecating EAPIs 0 and 1, I'd suggest we deprecate EAPIs 1
and 2, though. As others have recalled, we'll have to maintain EAPI 0
around indefinitely, and EAPI 3 includes all the features in EAPIs 1 and
2. This way we can leave the system set packages alone.

> At a later time, the warning could be changed to an error. When most
> of the tree has been updated to EAPI 2 or newer, we could also think
> about actively converting the remaining ebuilds. (Currently this
> doesn't look feasible though, as about half of the tree is still at
> EAPI=0. [1])

Sounds a good idea (for EAPIs 1 and 2).

> Opinions?
> 
> Ulrich
> 
> [1] <http://blogs.gentoo.org/alexxy/2010/11/06/some-interesting-stats-about-gentoo-portage-tree/>
> 

One way we could drop EAPI 0 would be if we do a major review of tree
and repo formats to improve upgrade paths, which would however likely
require breaking backwards compatibility at such point.
I believe such a change would only be acceptable, if we would pack
enough features and safety measures that it would ensure another break
would not need to be done for a long time.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNIJeVAAoJEC8ZTXQF1qEPnpIQAM73/W5vvIz9DJjHKiSPp8OX
Z4ezg0lBiT5ZpeN4caY5jdhh0lRWE8raEDBKiCjJhm/lnkdqs3hpYx5ogHJxhGrM
2HkzF1wfDFt5/l0PnqhCyGlS6o/v/zN4w0d3TQKsl1hq5bz5fge2SCe37bZXSC/h
Did6ijW17wsu+OQOP4ihI7CibLy0G9khi+zDQBoKsC8UVwfzO013aRuVORySP+d+
fgyR4wMOgduVqlsIKqLBVMTRzPWCUDvmyGd2eVJ8zhl5i/n1Hnq8Pw3QTwSmK15s
wfUUQH7N7uuWgC8w2i2JEy717yzjB5CRZX54MIFgIk2zFxPZe6mBsMeafL9oPNeR
3J2qJvlULM7BOxjkdXakE+089TM3R3d32ul9qcBmnlWbpbxHwzH/h7dAoCRb1kwW
DVG9MS1FGRar7EnKLVKhDh554cG47vS15b6q0fOSbxKNyjKa28XJVR7GQNtjk85Z
ACJdG5J9yCidgWWyiCcdF6uDAKGOl6FqJDngGLVrXsSWyL6nuUA68hEAMfuC5Y3D
EIWsexsRqVT2tksZ8a/LlhpCH74ksbibrH5sLw/0P0qrhQvK3K0whfIXF+kjSVy9
qnixHkSYTWUDkYB8cWrBemroD6bLQvm8pzOurOrSKeLY8ax28H2Dqkz914W6H4Ae
3DYA5ct0nnFQV4FOvUzA
=nBkm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Petteri Räty]

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

On 01/02/2011 05:19 PM, Jorge Manuel B. S. Vicetto wrote:

> 
> 
> One way we could drop EAPI 0 would be if we do a major review of tree
> and repo formats to improve upgrade paths, which would however likely
> require breaking backwards compatibility at such point.
> I believe such a change would only be acceptable, if we would pack
> enough features and safety measures that it would ensure another break
> would not need to be done for a long time.
> 

It's quite likely that if you are currently on a system with Portage
that does not understand EAPI 1 there's so many obstacles along the
upgrade path that a clean install makes more sense. Maybe someone is
willing to test this so that we actually know if there is an upgrade
path from EAPI 0 available any more.

Regards,
Petteri


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

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Roy Bamford]

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

On 2011.01.02 16:02, Petteri Räty wrote:
> On 01/02/2011 05:19 PM, Jorge Manuel B. S. Vicetto wrote:
> 
> > 
> > 
> > One way we could drop EAPI 0 would be if we do a major review of
> tree
> > and repo formats to improve upgrade paths, which would however
> likely
> > require breaking backwards compatibility at such point.
> > I believe such a change would only be acceptable, if we would pack
> > enough features and safety measures that it would ensure another
> break
> > would not need to be done for a long time.
> > 
> 
> It's quite likely that if you are currently on a system with Portage
> that does not understand EAPI 1 there's so many obstacles along the
> upgrade path that a clean install makes more sense. Maybe someone is
> willing to test this so that we actually know if there is an upgrade
> path from EAPI 0 available any more.
> 
> Regards,
> Petteri
> 
> 

There is an upgrade path from a pure EAPI0 system but it starts with a 
visit to the tinderbox as portage and python block one another.

Some other interesting things along the way:- 
You need to incrementally update gcc and glibc as there is some 
mutual blockage there too.
libpng-1.2, xorg and libexpat too if the box is old enough. How far do 
you want to go back? 

Its a very educational experience but a reinstall is faster.
The real killer is that some core system packages need EAPI>0 to build.

Personally, I don't regard tinderbox as any part of any officially 
supported upgrade path.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees

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

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Joshua Saddler]

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

On Sun, 02 Jan 2011 19:24:14 +0000
Roy Bamford <neddyseagoon@gentoo.org> wrote:
> Some other interesting things along the way:- 
> You need to incrementally update gcc and glibc as there is some 
> mutual blockage there too.
> libpng-1.2, xorg and libexpat too if the box is old enough. How far
> do you want to go back? 
> 
> Its a very educational experience but a reinstall is faster.
> The real killer is that some core system packages need EAPI>0 to
> build.
> 
> Personally, I don't regard tinderbox as any part of any officially 
> supported upgrade path.

Up until the present EAPI era, we've supported upgrading from very
ancient systems. We've never required users to completely reinstall.
Check our upgrade doc:

http://www.gentoo.org/doc/en/gentoo-upgrading.xml

There's a constant stream of help requests on the forums and IRC from
folks upgrading from years-old installations. Usually it's from fokls
who've been given some never-updated, faithfully running Gentoo
server, sometimes from the pre-2004.X days. Our upgrade instructions
work to a point, and then Portage/python and other system packages
stop working, thanks to the differing EAPI versions. And *then*, as
Roy mentioned, there's the whole separate
rebuild-expat-and-similar-libs sequence of failures.

These are the kinds of things for which there's no canonical,
official upgrade path. It's entirely trial-by-error, which sucks for
end users who were expecting to follow our upgrade guide as-is, but
then the EAPI shifts bit 'em in the butt. Users should not be told
"just reinstall," since often that's not an option.

Whatever you folks eventually settle on, please send patches and
suggestions to the GDP for our upgrade guide. I'd prefer that users
have a possible upgrade path from *any* profile/version of Gentoo up
through the present. If you decide not to support anything older than
version X and require reinstalling or some other set of procedures,
please let the GDP know via our ML or bugzilla.

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

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Petteri Räty]

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

On 01/02/2011 11:04 PM, Joshua Saddler wrote:
> 
> Whatever you folks eventually settle on, please send patches and
> suggestions to the GDP for our upgrade guide. I'd prefer that users
> have a possible upgrade path from *any* profile/version of Gentoo up
> through the present. If you decide not to support anything older than
> version X and require reinstalling or some other set of procedures,
> please let the GDP know via our ML or bugzilla.
>

The current hard requirement is one year:
http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt

The follow up discussion probably didn't end up in any concrete
decisions. If we want to actually make sure upgrades from old installs
(>1 year) work then we should setup some kind of a bot doing upgrades.
It would then provide the documentation for the upgrade path and make
sure it keeps working.

Regards,
Petteri


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

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Dale]

Petteri Räty wrote:
> On 01/02/2011 11:04 PM, Joshua Saddler wrote:
>    
>> Whatever you folks eventually settle on, please send patches and
>> suggestions to the GDP for our upgrade guide. I'd prefer that users
>> have a possible upgrade path from *any* profile/version of Gentoo up
>> through the present. If you decide not to support anything older than
>> version X and require reinstalling or some other set of procedures,
>> please let the GDP know via our ML or bugzilla.
>>
>>      
> The current hard requirement is one year:
> http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt
>
> The follow up discussion probably didn't end up in any concrete
> decisions. If we want to actually make sure upgrades from old installs
> (>1 year) work then we should setup some kind of a bot doing upgrades.
> It would then provide the documentation for the upgrade path and make
> sure it keeps working.
>
> Regards,
> Petteri
>
>    

As a regular reader of gentoo-user, if someone has not updated in more than a year, we almost always recommend a re-install.  Maybe save /etc, /home and the world file and then start from scratch on the rest.  As a user since the 1.4 days, I would never expect that much backward compatibility.  The OS just has to many changes to be able to do that.

Also, I think going back that far would mean holding up progress as well.  It's hard to move forward if all you worry about is the past.  It's good to learn from the past but not to use it as a boat anchor.

That said, if there was some radical change that required a reinstall and the grass was much greener on the other side, I would do it.  That's just me.  I'm not sure what would require that to happen but thought it worth mentioning.  I wouldn't want that to happen to often tho.  It's not like the install is point, click and walk away.  o_O

My $0.02 worth.

Dale

:-)  :-)

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Rich Freeman]

On Sun, Jan 2, 2011 at 4:46 PM, Dale <rdalek1967@gmail.com> wrote:
> As a regular reader of gentoo-user, if someone has not updated in more than
> a year, we almost always recommend a re-install.  Maybe save /etc, /home and
> the world file and then start from scratch on the rest.  As a user since the
> 1.4 days, I would never expect that much backward compatibility.  The OS
> just has to many changes to be able to do that.

Something I've done when I've really borked up my system is to just
save /etc, backup, etc, and then extract a stage3 over my root
filesystem.  That gets all of my system packages into a working state.
 Sure, some packages may not work, but many still will.  Then an
emerge -e world or whatever will clean things up.

Sure, you'll end up with a lot of orphan cruft, but that probably
won't hurt anything.  After a few months of happy operation various
orphan-finding scripts can help with cleanup.

This may not always work, but is probably easier than a full rebuild.

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Enrico Weigelt]

* Rich Freeman <rich0@gentoo.org> schrieb:

> Something I've done when I've really borked up my system is to just
> save /etc, backup, etc, and then extract a stage3 over my root
> filesystem.  That gets all of my system packages into a working state.
>  Sure, some packages may not work, but many still will.  Then an
> emerge -e world or whatever will clean things up.

Assuming there are no circular deps which can only be resolved
by temporarily changing some useflags ... ;-o


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

[Jeroen Roovers]

On Sun, 02 Jan 2011 18:02:48 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> It's quite likely that if you are currently on a system with Portage
> that does not understand EAPI 1 there's so many obstacles along the
> upgrade path that a clean install makes more sense. Maybe someone is
> willing to test this so that we actually know if there is an upgrade
> path from EAPI 0 available any more.

One recent example is [1] (which the reporter ended up closing as
WONTFIX himself). In that particular case, $someone could roll out newer
stages based on the current tree. I think he just gave up, which is a
bit of a pity.


     jer


[1] https://bugs.gentoo.org/show_bug.cgi?id=346621

Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

[Andreas K. Huettel]

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


We have to be precise about what we are talking here:

1) for NEW ebuilds added to the tree...
>
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

it would definitely make sense to trigger a warning whenever an ancient EAPI is 
used. Remember, we're adding new features so we can use them - and we also 
want to train new recruits for using these features. 

So, I'm for a repoman warning for NEW ebuilds whenever EAPI<(CURRENT_EAPI-1). 
This would at the moment deprecate EAPI=0,1 (and soon also 2).

2) for existing ebuilds...

... it is indeed impractical to force EAPI=0 rewriting. Some of the in-between 
steps however should be deprecated. Eg. EAPI=1 and later EAPI=2...

My 2ct...

Cheers, Andreas
 

-- 
 
Andreas K. Huettel
dilfridge@gentoo.org
http://www.akhuettel.de/

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