Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
Rick \Zero_Chaos\ Farina zeroch...@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
On 29/09/13 04:12, hero...@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
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
-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
Rick \Zero_Chaos\ Farina zeroch...@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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2013 10:12 PM, hero...@gentoo.org wrote: Rick \Zero_Chaos\ Farina zeroch...@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-
[gentoo-dev] Gentoo Upgrade Guide and EAPI
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
