[gentoo-dev] Gentoo Upgrade Guide and EAPI

[gentoo-dev] Gentoo Upgrade Guide and EAPI

[heroxbd]

Dear Fellows,

I am revisiting this topic based on previous discussions[1,2,3].

There seems to be a constant need for toolchain with a new EAPI. The
only block is "how can we upgrade from an ancient system?", "don't bump
or the upgrade path will be break". Let's figure out a solid upgrade
path consciously, with a test farm of ancient systems, and then bump the
EAPI of toolchain.

Besides the upgrading guide[4] suggesting a chroot, rich0 had some
experiences with a live overwriting of latest stage3 to /, recently I've
heard from patrick of a script to bootstrap Gentoo lively on an existing
system (be it Debian, Red Hat or an ancient Gentoo).

Here is another alternative from Prefix (upgrading the kernel is mostly
independent):

  a. we distribute a stage3 of Gentoo RAP(i.e. Prefix with libc), with
     EPREFIX pointing to, say, /tmp/upgrade
  b. sync the potage tree in the host system, switch it to the newest
     profile.
  c. PORTAGE_OVERRIDE_EPREFIX=/ /tmp/upgrade/usr/bin/emerge -e world

It has the same solidity as the chroot while being easier without the
need to mount back and forth. It can track installed files properly as
opposed to overwriting /.

This needs a lot of work to do the testing. At the same time, there are
definitely a dozen of developers who want to bump the EAPI of
toolchain. Let's share the workload.


vapier, if we can figure out a solid and easy solution for upgrading
ancient Gentoo, would you agree on bumping the EAPI of toolchain?


Cheers,
Benda

1. http://thread.gmane.org/gmane.linux.gentoo.devel/86803
2. http://article.gmane.org/gmane.linux.gentoo.devel/73767
3. http://article.gmane.org/gmane.linux.gentoo.project/2841
4. http://www.gentoo.org/doc/en/gentoo-upgrading.xml

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[Ulrich Mueller]

>>>>> On Sat, 28 Sep 2013, heroxbd  wrote:

> I am revisiting this topic based on previous discussions[1,2,3].

> There seems to be a constant need for toolchain with a new EAPI. The
> only block is "how can we upgrade from an ancient system?", "don't
> bump or the upgrade path will be break". Let's figure out a solid
> upgrade path consciously, with a test farm of ancient systems, and
> then bump the EAPI of toolchain.

The upgrade path is not at all what is blocking this. In its 20130409
meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no
longer required for the upgrade path of users' systems."

The reason why toolchain packages are still at EAPI 0 was explained in
this posting:
http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377

AFAICS, changing that is entirely the task of the toolchain team.

Ulrich

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[Rick "Zero_Chaos" Farina]

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

On 09/28/2013 03:00 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 28 Sep 2013, heroxbd  wrote:
> 
>> I am revisiting this topic based on previous discussions[1,2,3].
> 
>> There seems to be a constant need for toolchain with a new EAPI. The
>> only block is "how can we upgrade from an ancient system?", "don't
>> bump or the upgrade path will be break". Let's figure out a solid
>> upgrade path consciously, with a test farm of ancient systems, and
>> then bump the EAPI of toolchain.
> 
> The upgrade path is not at all what is blocking this. In its 20130409
> meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no
> longer required for the upgrade path of users' systems."
> 
> The reason why toolchain packages are still at EAPI 0 was explained in
> this posting:
> http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377
> 
> AFAICS, changing that is entirely the task of the toolchain team.
> 
Yes, it is entirely the task of the toolchain team, and looks like
heroxbd joined the toolchain team and would like to push the rest of his
team for this update. Something I greatly thank him for.

I don't think any dev wants to (or really could) force toolchain to
update individually, however, if motivated people want to join the team
and help, his question appeared to be will it be permitted to be updated.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSRwnhAAoJEKXdFCfdEflKVycP/RrDx0riRF9HO8yjMlPxPRmX
Fm4xl+KdGNiKIxHDKVKGehyHDGyEVxUq8ZtrNqkQurtgibhtI2eErOjWYVHsV2Yj
A2lW8JubwvYn14Qk0Pem9jg5cGTbo1mEA4UGG2XMWYzyGJkXi/m+alJYTQfZpbGk
VKwll6wAMpPpVoV/xAA/mHX5AJrALQrP9/0xqOtvcSSvJTZvu4rpLFPWRlUf6Q6C
Z+0grxc3x6Nq6Ryn6f39KLRYgXv6AEwx9ieajKu7ES+rBbTWsJCHtPD+H3zZbJI8
g+/2GPMgDmQ9tMQwuBwPdylUzGhPwd8Gmd6546mnBPOlZZNsJxBc/Cqt1paMyaPy
sZp2igbXR5B9ha6Tg5bW7j6WDKqr9QZAslGYrXJa25wwmvcBQV+EsJrmmpQbDCdi
todWjippnmJATDHVsHR1tW11/iO0t6UUKI8jLZm7HCaGXRptILWfICYYXAM19ntq
9DWpA4BIpQzZx0s3cQZ1eIB3lHxPL387UWitAI9zW23Q0VYfddQgbLKbAo76GkR7
3ta6wjvIJ2vPBgxvv5Eo/hfKMUtxxyGeA/Jp6+zRMKPxcsqBocQXMs7pdmTON3Mb
ddDLJ88tPc9QenHzE4PwCiTjSPDCSQRzrhmzt1iQEsIitVXDnL5kXGt38MfxT9We
7p2PfdN8P4VekqKIcEVT
=ROKo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[heroxbd]

"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> writes:

> On 09/28/2013 03:00 AM, Ulrich Mueller wrote:
>>>>>>> On Sat, 28 Sep 2013, heroxbd  wrote:
>> 
>>> I am revisiting this topic based on previous discussions[1,2,3].
>> 
>>> There seems to be a constant need for toolchain with a new EAPI. The
>>> only block is "how can we upgrade from an ancient system?", "don't
>>> bump or the upgrade path will be break". Let's figure out a solid
>>> upgrade path consciously, with a test farm of ancient systems, and
>>> then bump the EAPI of toolchain.
>> 
>> The upgrade path is not at all what is blocking this. In its 20130409
>> meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no
>> longer required for the upgrade path of users' systems."
>> 
>> The reason why toolchain packages are still at EAPI 0 was explained in
>> this posting:
>> http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377
>> 
>> AFAICS, changing that is entirely the task of the toolchain team.

Thank you for the clarification, Ulrich.

> Yes, it is entirely the task of the toolchain team, and looks like
> heroxbd joined the toolchain team and would like to push the rest of his
> team for this update. Something I greatly thank him for.
>
> I don't think any dev wants to (or really could) force toolchain to
> update individually, however, if motivated people want to join the team
> and help, his question appeared to be will it be permitted to be
> updated.

Can't agree with you more.

It's just a starting point, though. I still don't have a clear plan yet.

After reading carefully the thread Ulrich pointed out, it seems that
refactoring ebuild/eclass is invevitable, which calls for an overlay to
carry it on.

Benda

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[Rick "Zero_Chaos" Farina]

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

On 09/28/2013 10:12 PM, heroxbd@gentoo.org wrote:
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> writes:
> 
>> On 09/28/2013 03:00 AM, Ulrich Mueller wrote:
>>>>>>>> On Sat, 28 Sep 2013, heroxbd  wrote:
>>>
>>>> I am revisiting this topic based on previous discussions[1,2,3].
>>>
>>>> There seems to be a constant need for toolchain with a new EAPI. The
>>>> only block is "how can we upgrade from an ancient system?", "don't
>>>> bump or the upgrade path will be break". Let's figure out a solid
>>>> upgrade path consciously, with a test farm of ancient systems, and
>>>> then bump the EAPI of toolchain.
>>>
>>> The upgrade path is not at all what is blocking this. In its 20130409
>>> meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no
>>> longer required for the upgrade path of users' systems."
>>>
>>> The reason why toolchain packages are still at EAPI 0 was explained in
>>> this posting:
>>> http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377
>>>
>>> AFAICS, changing that is entirely the task of the toolchain team.
> 
> Thank you for the clarification, Ulrich.
> 
>> Yes, it is entirely the task of the toolchain team, and looks like
>> heroxbd joined the toolchain team and would like to push the rest of his
>> team for this update. Something I greatly thank him for.
>>
>> I don't think any dev wants to (or really could) force toolchain to
>> update individually, however, if motivated people want to join the team
>> and help, his question appeared to be will it be permitted to be
>> updated.
> 
> Can't agree with you more.
> 
> It's just a starting point, though. I still don't have a clear plan yet.
> 
> After reading carefully the thread Ulrich pointed out, it seems that
> refactoring ebuild/eclass is invevitable, which calls for an overlay to
> carry it on.
> 
While I'm not nearly good enough to detail how this should happen
exactly, please, may I beg, do an eclass revision for this.  The fact
that this hasn't been done clearly implies it is a lot of work.  Let's
not risk stable, let's simply make toolchain-r1.eclass or whatever, and
bump that to eapi5.  At the end of the day, this allows working and
testing without odd issues, and if everyone really hates that idea you
can simply drop the changes into the original eclass when it's all done.

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSR5V3AAoJEKXdFCfdEflKDcMP/0B01NSlVaTEM6oDIF324YNP
p1G1vNVh86avVCL+0sLfmDPID547qWZOfemoids94xemrvyVYnJFccvtg7KBH+ck
k4h/LJ2pTEvCGiL3KyUngYc6XN3YMwOHJsRD+jr0cmYG+GG0Lm5UUb73PPhgLtOv
Ltrm4B68w3x1qqucrd3/PgBF7tfjoBdvB8XqkJ+u9RoMFfFb2BUH3n6VZ2Ngkzup
BU5PaakC8tBGhZvkLrd81RHTY7iHuM5HGh4ZK0GSfVsq+pYIwFpWztKGcSQmEpxe
oLgMZD2g5GAykkUhzcrvc6p091wsOylenAgnhZZL2cy2pZE99TLTUw6y/Q7+HUiN
mKdXG/JbXQ/FmkhqVivvWM43g3bumEvYub5EegUa6MGrHjCqRjsO+GQq68CGTbMq
TYpZXUGtCdAdMIyvk6wMhTWlrO2TQmakkj/tqHif1TsyVIIYZlTKLosftqxVbpxd
54Mr1oI+LM7oHGghy5/7BJz0V0U7BWIXiDBBf4HJ1k4gybkRBqCx7I+YSYib9ZZg
jvHwJv9kiksduO5dQk/NmKgWgmyBTaYzZYPvxJyXp2uzk3Nmgf7JAwN2AHuUrFXZ
5LLwPC36bwEyAdKABHwIZsVdquBm2smFLIFy4oMoxcmEHBaOmOKBSrIKN0iLPYnD
ZfpgorrlwCLdiqV+VeKU
=jY8E
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[Luca Barbato]

On 29/09/13 04:12, heroxbd@gentoo.org wrote:
> It's just a starting point, though. I still don't have a clear plan yet.
> 
> After reading carefully the thread Ulrich pointed out, it seems that
> refactoring ebuild/eclass is invevitable, which calls for an overlay to
> carry it on.

That would be much welcome, having new people in toolchain and trying to
get new useful stuff done while we aren't breaking our users (hint, some
people are already sad for the /usr thing) seems a good idea.

lu - still too busy with stuff...

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[heroxbd]

"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> writes:

> While I'm not nearly good enough to detail how this should happen
> exactly, please, may I beg, do an eclass revision for this.  

There is an r1 candidate as Paweł initiated (bug 474358)

> The fact that this hasn't been done clearly implies it is a lot of
> work.  Let's not risk stable, let's simply make toolchain-r1.eclass or
> whatever, and bump that to eapi5.  At the end of the day, this allows
> working and testing without odd issues, and if everyone really hates
> that idea you can simply drop the changes into the original eclass
> when it's all done.

Having a unstable eclass as toolchain-r1.eclass in tree might not be a
good idea compared to an overlay though.

Regarding eclass, I have a question: Why do we keep all old versions of
gcc and glibc? If the point is only being upgradable from old Gentoo, is
the requirement lefted now? If it is for users who need a specific
version of gcc/glibc, why don't we create a toolchain-archive overlay
for that purpose? In the overlay we can have historical snapshots of
toolchain.eclass, too.

Keeping only a few version of gcc in tree will ease the maintenance of
toolchain eclass a lot.

Benda

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

["Paweł Hajdan, Jr."]

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

On 9/30/13 1:31 AM, heroxbd@gentoo.org wrote:
> Having a unstable eclass as toolchain-r1.eclass in tree might not be a
> good idea compared to an overlay though.

If that's the case, it should be pretty straightforward to create an
overlay with that eclass, either under toolchain-r1 or just
toolchain.eclass name.

> Regarding eclass, I have a question: Why do we keep all old versions of
> gcc and glibc? If the point is only being upgradable from old Gentoo, is
> the requirement lefted now? If it is for users who need a specific
> version of gcc/glibc, why don't we create a toolchain-archive overlay
> for that purpose? In the overlay we can have historical snapshots of
> toolchain.eclass, too.

I think that idea is worth exploring.

> Keeping only a few version of gcc in tree will ease the maintenance of
> toolchain eclass a lot.

+1

Paweł



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