Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote: Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. Why should I have to run more packages from ~arch than I absolutely need to? We all know that upgrading more software than absolutely necessary will result in bad things happening to a computer. The easiest solution to the problem with ~arch having the only working versions of some packages is to get more of those packages stabilized. But, we all know that the manpower required simply doesn't exist.
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. With all of these problems, it sounds like in your case, our stable tree isn't living up to our hopes. *This* is the problem you should be bringing to our attention, instead of complications with portage and EAPI. I looked up your email address on bugzilla, hoping to find at least 5 bug reports, one for each of the problems you describe above. I could only find one (and even that one doesn't really make clear the fact that the current stable has problems which is affecting your schoolwork). Please could you fix that? Thanks! Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
why offlist? Robert R. Russell wrote: Stabilization reports for ~xorg-x11 and the ~xf86-video-intel drivers aren't likely to go any where given the number of issues people are asking about on the forums But the important thing is that you notify the maintainers that you're in trouble. That may encourage them to focus more on the remaining blockers. But at the very minimum it makes them aware, and it serves as documentation for others who may hit the same problem. and the time taken to fix even simple bugs like this one https://bugs.gentoo.org/show_bug.cgi?id=227895 You can't judge the whole of Gentoo on your experience with one bug. It is also not an excuse for not filing the bugs, even if they take a while to get fixed. A user reporting the problem is just as significant as a developer fixing it. A more accurate guide to what the devs want on a filed bug report or a reply to a bug report( patches to the ebuilds, patches to the software, and the like) would help me out in giving the devs what they need or want. Suggestions appreciated. My advice would be, if something is broken, then file a bug (after doing some sanity checking to attempt to confirm it's not your fault, and nobody else has filed it). As far as the kile stabilization report, what priority do stabilization reports need? Do I need to give exact details on what doesn't work in the old version compared to the new version, which is unlikely because I can't even remember the problem that forced an upgrade? I wouldn't bother with the priority field. But information on the benefits and importance of stabling is important. Give developers motivation to fix the bug, by describing what problems the stabilisation solves. The end of school will also help with the bug filling rate going up in the next week or so. Great! Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell [EMAIL PROTECTED] writes: 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Another reason for preferring option 3 for bug fix (but not for 'cosmetic' changes or ones which prevent some users from installing the package) is that (~arch) users will already have the pre-bug fixed version installed and portage will not install the bug fix unless either the version is bumped or USE flags have changed and the --newuse emerge option is used.
Re: [gentoo-dev] EAPI 2 policy for portage tree
Jean-Marc Hengen wrote: tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. [snip] the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. Just FYI, there's no difference -- when you've chosen to use the ~arch version, you *have* to follow any updates to it as soon as possible if you want to be reasonably sure you aren't affected by a security bug, as our security team doesn't issue GLSAs for ~arch packages. Sticking with a version that works for you doesn't mean you're somehow protected form security bugs. So to put this into perspective with cmake -- if there was a security bug in current version (which you'd keep as you don't want to upgrade Portage) and the fix for this bug would be using EAPI=2 (which is not an unrealistic situation), you'd be affected. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] EAPI 2 policy for portage tree
Hi, I like to write about an observation about gentoo, I made the past weeks, which does frustrate me personally a little bit, mainly because it makes administration a bit harder for me. It could be considered as an issue or as yet another case of When you play with unstable packages, you're on your own.. It's about EAPI 2 and maybe it isn't worth changing anything with portage 2.1.6 on the way, but I guess, with future EAPI's such a situation could be repeated, so maybe there's interest in discussing it. If I'm to late and missed the discussion, I apologize for the spam. This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages after checking, what can go wrong with the unstable package and if I can afford the worst case. Generally I consider portage to be a no-go as unstable package. So I'm in the situation, where I used cmake-2.6.2 on a daily basis and like to continue, but I can't with the current state of tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. This isn't the first issue I had with EAPI 2, but they were until now always upgrades to new version or new packages, so I abandoned and stayed with the current version or didn't install the package at all and wait for stable portage with EAPI 2 support. Up till now I could always do without those packages, but if I needed one necessarily, I guess, I would have backported the ebuild to a older EAPI, rather than upgrading portage. What I don't want to say, is that EAPI 2 should be blocked, rather the contrary, I look forward to EAPI 2, but from my perspective, in the particular case of cmake described above, I rather had added a new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. So persons like me know, that they have to decide, what to do. Certainly one can have a different approach (like the one, that the maintainer of cmake took), which I do accept and what I descriped would be my solution. So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. With kind regards, Jean-Marc Hengen, a happy gentoo user
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote: So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. As a arch developer and mostly stable user, I also find this very frustrating. I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:11 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... That also means that to pull a significant number of ebuilds it forces mostly everyone to test it.. and that part is annoying.. The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:29 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:25:44 -0500 Olivier Crête [EMAIL PROTECTED] wrote: The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... Uh, regression testing's handled by the package manager's extensive set of unit tests, which can cover this with targetted accuracy with much more reliability than making sure random ebuilds still work. We all know that portage doesn't have an extensive testing suite... And that test suites can't cover all the cases that the whole tree does... What you're suggesting here is making everyone wait four more months for no increase in safety. I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Mon, 08 Dec 2008 19:25:44 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
The can be tested properly phase is when it's in ~arch...
That also means that to pull a significant number of ebuilds it forces
mostly everyone to test it.. and that part is annoying..
If you don't like it, don't run ~arch.
I have to agree with Ciaran on this one.
Furthermore, it's unrealist and to an extent unfair to impose
limitations on ~arch ebuilds because of arch users. Gentoo should
support arch users, but that doesn't mean making sure ~arch ebuilds
work for arch users. When a arch user opts to use an ~arch ebuild,
he/she does so at his own risk.
About replacing EAPI-{0,1} ebuilds with EAPI-2 ebuilds, I can agree
with the proposal, although one can pick earlier versions/revisions from
http://sources.gentoo.org/viewcvs.py/gentoo-x86/
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk9zYcACgkQcAWygvVEyAKEmQCfblj0GaZSITsF6/L0PvZVBLyA
1QsAoIote0hbzetNbcrPvWUpTuIOPITW
=XnAf
-END PGP SIGNATURE-
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote: snip This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages snip With kind regards, Jean-Marc Hengen, a happy gentoo user The problem is not that an EAPI 2 supporting portage is unstable or that he is using a ~arch version of one particular package, but the during a bugfix the maintainer moved the ebuild to EAPI 2 without a version bump forcing Jean-Marc to downgrade to the stable version. The question on policy is, can a maintainer upgrade an ebuild to the latest EAPI while doing some other bugfixing without a version bump? My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg).
