Re: [gentoo-dev] Deprecate EAPIs 1 and 2?
On Sun, 02 Jan 2011 18:02:48 +0200 Petteri Räty betelge...@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 1 and 2?
-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?
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecate EAPIs 1 and 2?
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 EAPI0 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 pgp5vUVecLO99.pgp Description: PGP signature
Re: [gentoo-dev] Deprecate EAPIs 1 and 2?
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecate EAPIs 1 and 2?
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?
On Sun, Jan 2, 2011 at 4:46 PM, Dale rdalek1...@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?
* Rich Freeman ri...@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: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --