On a freshly unpacked stage3 (stage3-amd64-20100617.tar.bz2) there are two versions of python: dev-lang/python-2.6.5-r2 and dev-lang/python-3.1.2-r3 I don't see why the latter is needed.
+1
python-3 is there because its marked stable and some package deps on it, then some other packages deps on 2.6 only. If you don't want it on stage3, simply mark it unstable...if python-3 doesn't make sense on a stage3, then it doesn't make sense on stable either
Python 3 is stable, because some stable packages need or will need Python 3.
(In reply to comment #3) > Python 3 is stable, because some stable packages need or will need Python 3. > That's a wonderful executive answer. Sounds great but no content. Name one program on a stage3 that needs Python 3 and won't work with Python 2.
(In reply to comment #4) > (In reply to comment #3) > > Python 3 is stable, because some stable packages need or will need Python 3. > > That's a wonderful executive answer. Sounds great but no content. > Name one program on a stage3 that needs Python 3 and won't work with Python 2. The packages, which need Python 3, probably aren't in stage3.
22:31:04 < Arfrever> a3li: Python 3 isn't required in stage3. #gentoo-council, today.
I'm closing this bug as there's nothing the RelEng team can do about this. As Raúl explained, python3 is pulled into the stage as a dependency to one of the packages in the system set or because of the "magic" being done in the python eclass and or eselect module. If you really want this to be fixed, then please reopen and reassign to the python team.
(In reply to comment #7) > If you really want this to be fixed, then please reopen and reassign to the > python team. > Of course I want it fixed. Otherwise I would have not filed the bug.
(In reply to comment #7) > I'm closing this bug as there's nothing the RelEng team can do about this. I completely fail to interpret this response as anything other than trolling. I don't know what other bug trackers you use, but this, Gentoo's bug tracker, sees a lot of misassignments and reassignments, and no Assignee should be regarded as "final" and the response should never be WONTFIX or CANTFIX when the Assignee cannot fix the problem, particularly when another Assignee might be able to.
(In reply to comment #9) > (In reply to comment #7) > > I'm closing this bug as there's nothing the RelEng team can do about this. > > I completely fail to interpret this response as anything other than trolling. I Jeroen, this bug was opened and assigned to the Release Engineering team. From a RelEng point of view, what I saw was people trying to shove into RelEng the responsibility to fix a *major* mess that was created in the tree with the way Python is being handled lately. How is it trolling to close a bug stating that the RelEng team CANTFIX this for the reasons that have been presented in this bug and on the mls? Furthermore, I was clear that if Alex wished to proceed further, this bug should be reassigned to the python team as they're the only ones that can fix this up.
If you can find a wrong dependency (e.g. dev-lang/python instead of =dev-lang/python-2*), which causes that Python 3 is in the stages, then we will fix it. The more reliable way would be to make catalyst run 'emerge -C =dev-lang/python-3*'. (In reply to comment #10) > From a RelEng point of view, what I saw was people trying to shove into > RelEng the responsibility to fix a *major* mess that was created in the tree > with the way Python is being handled lately. Actually the only problem was handling of /usr/bin/python{,2,3} symlinks.
(In reply to comment #11) > If you can find a wrong dependency (e.g. dev-lang/python instead of > =dev-lang/python-2*), which causes that Python 3 is in the stages, then we will > fix it. > > The more reliable way would be to make catalyst run 'emerge -C > =dev-lang/python-3*'. As has been explained many times already, we won't start adding exceptions for stuff like this. The general rule on Gentoo is that you should use the highest visible version of a package. It's up to maintainers to ensure that the highest visible version is an appropriate one and not to RelEng. > (In reply to comment #10) > > From a RelEng point of view, what I saw was people trying to shove into > > RelEng the responsibility to fix a *major* mess that was created in the tree > > with the way Python is being handled lately. > > Actually the only problem was handling of /usr/bin/python{,2,3} symlinks. No. As you know very well, many people around here, including a few very vocal developers, completely disagree with the current state of python in the tree. My point is that RelEng is being pulled to an argument it doesn't want to be a part of. We just want / need a stable tree that works.
(In reply to comment #10) > this bug was opened and assigned to the Release Engineering team. And you couldn't do anything so you could have reassigned to bug-wranglers, to the reporter, and if you were really brave, to any team you thought should fix the bug, but instead you forced this needless CLOSED, REOPENED, reassignment cycle. So next time, just assign to bug-wranglers: that's what the alias is for. > From a RelEng point of view, what I saw was people trying to shove into RelEng > the responsibility to fix a *major* mess that was created in the tree with the > way Python is being handled lately. > How is it trolling to close a bug stating that the RelEng team CANTFIX this for > the reasons that have been presented in this bug and on the mls? Furthermore, I > was clear that if Alex wished to proceed further, this bug should be reassigned > to the python team as they're the only ones that can fix this up. It's impossible to reassign a CLOSED bug without changing it to REOPENED. If instead a new bug report needs to be filed and assigned to the "correct" alias, what do you propose we do with the original report? In the end, we had a bug report already and a huge number of comments - all the information gathered in one place, so closing it as CANTFIX is simply an abuse of procedure. Now could we perhaps have some peace and let this bug report age like a fine wine while arf still has a headlock on python@? Maybe his successor will finally fix this bug, or anyone who dares touch python in his presence. :)
Call us back when something changes in here and there's anything we can do about this.
This is getting ridiculous. We have *regularly* users asking in #gentoo about random failures due to this and I personally don't care for the extra weight. Arfrever of course has no intention of fixing this, so he'll just sit it out. Council, I wish this to be part of your next meeting.
(In reply to comment #15) > This is getting ridiculous. > We have *regularly* users asking in #gentoo about random failures due to this > and I personally don't care for the extra weight. > Arfrever of course has no intention of fixing this, so he'll just sit it out. > > Council, I wish this to be part of your next meeting. Alex, what part of the issue (python3) are you talking about? All the build issues with stage3 related to python that I'm aware of were caused by having python3 as the default interpreter. That was fixed again a few weeks ago. Or are you aware of any failures caused by the simple presence of python3 in the stages? (I'm using my council hat here as I consider this "fixed" for my "releng" hat - assuming there are no build failures just because python3 is present in the stages)
(In reply to comment #16) > (In reply to comment #15) > > This is getting ridiculous. > > We have *regularly* users asking in #gentoo about random failures due to this > > and I personally don't care for the extra weight. > > Arfrever of course has no intention of fixing this, so he'll just sit it out. > > > > Council, I wish this to be part of your next meeting. > > Alex, > > what part of the issue (python3) are you talking about? All the build issues > with stage3 related to python that I'm aware of were caused by having python3 > as the default interpreter. That was fixed again a few weeks ago. Or are you > aware of any failures caused by the simple presence of python3 in the stages? > The root problem is that python 3 is stable, and that for a moot reason (it was 'that people who want to test their software can do so easily'). It triggers the fail cascade, inclusion in the stages, and finally setting it default. Reverting that stabilization is likely not possible. What should be possible though is removing it from the stages. It was ascertained that it is not needed (comment 6), so it should be gone, not only for size's sake (heck, we don't even have a dhcp client, why the hell should a useless python version have the privilege of being in there?) I am not aware of failures per-se, but it allows for stupid mistakes. If it's there some people will make it default (it's newer and stuff, so it must be better, right?) and then come ask for help. It's tiring. > (I'm using my council hat here as I consider this "fixed" for my "releng" hat - > assuming there are no build failures just because python3 is present in the > stages) Interesting, releng considers this as fixed and so doesn't care for useless weight in stages? Nice.
(In reply to comment #17) > (In reply to comment #16) > I am not aware of failures per-se, but it allows for stupid mistakes. If it's > there some people will make it default (it's newer and stuff, so it must be > better, right?) and then come ask for help. It's tiring. OK, so there aren't new issues then. > > (I'm using my council hat here as I consider this "fixed" for my "releng" hat - > > assuming there are no build failures just because python3 is present in the > > stages) > > Interesting, releng considers this as fixed and so doesn't care for useless > weight in stages? Nice. Let me rephrase the above: Releng considers the issue to come from a python team decision that has lead to the current "state of affairs" in which releng has no interest to participate. To address one issue you mentioned, no matter how much the python team (Arfrever) wishes to claim otherwise, releng isn't doing anything to pull python3 into the stage. It gets pulled in by Portage using the latest visible version of a package in the dependency tree. The argument on this bug has been about forcing releng to add a "manual hack" to the stage building to uninstall python3 after it gets pulled in.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > I am not aware of failures per-se, but it allows for stupid mistakes. If it's > > there some people will make it default (it's newer and stuff, so it must be > > better, right?) and then come ask for help. It's tiring. > > OK, so there aren't new issues then. > Yeah, just the existing ones. > > > (I'm using my council hat here as I consider this "fixed" for my "releng" hat - > > > assuming there are no build failures just because python3 is present in the > > > stages) > > > > Interesting, releng considers this as fixed and so doesn't care for useless > > weight in stages? Nice. > > Let me rephrase the above: Releng considers the issue to come from a python > team decision that has lead to the current "state of affairs" in which releng > has no interest to participate. Maybe the Council should evaluate this decision and the general route that Python on Gentoo currently follows. > > To address one issue you mentioned, no matter how much the python team > (Arfrever) wishes to claim otherwise, releng isn't doing anything to pull > python3 into the stage. It gets pulled in by Portage using the latest visible > version of a package in the dependency tree. The argument on this bug has been > about forcing releng to add a "manual hack" to the stage building to uninstall > python3 after it gets pulled in. So maybe we need a more high-level approach at fixing this (read: py3k back to ~arch)? Or are there other ways that you can think of?
(In reply to comment #19) > Maybe the Council should evaluate this decision and the general route that > Python on Gentoo currently follows. That might be a good idea, just to settle this for once and for all. As the current Python team lead, I do think that Python 3 should be available from the stable tree, but I don't think that it should be the default anywhere. > So maybe we need a more high-level approach at fixing this (read: py3k back to > ~arch)? Or are there other ways that you can think of? In this case it would seem to make the most sense to somehow fix the way portage depends on Python. I.e. have it depend on (python-2.* || python-3.*) in some way that ensures it will always pick the former by default, but will also work if only python3 is installed (which is probably a theoretical scenario at this point). I wouldn't mind having portage just depend on python2, although that seems quite a bit more hacky.
(In reply to comment #20) > (In reply to comment #19) > > So maybe we need a more high-level approach at fixing this (read: py3k back to > > ~arch)? Or are there other ways that you can think of? > > In this case it would seem to make the most sense to somehow fix the way > portage depends on Python. I.e. have it depend on (python-2.* || python-3.*) in > some way that ensures it will always pick the former by default, but will also > work if only python3 is installed (which is probably a theoretical scenario at > this point). I wouldn't mind having portage just depend on python2, although > that seems quite a bit more hacky. Dropping python-3 from the stable tree would seem the more obvious way to address this and the most "canonical" way on Gentoo. Dirkjan, the problem with your suggestion, which has been the same made by the python team members for a long time now, is that basically you want to change the way the package managers work. Currently, afaik, the resolution process is meant to be "greedy" in that it should by default pick the highest visible version of a package available. One way I can think to address this issue, would be to have python3 as a separate package, but then we would get in the discussion of having different packages for different releases, which is frowned upon in Gentoo. I'm also not sure how that would work with virtuals and how to allow multiple versions installed in the same system.
I was not suggesting to change the dependency resolution algorithm for the package manager, I was suggesting that it might be possible to change the specific dependencies in the portage ebuild in some way that they can be satisfied without pulling in python-3. Anyway, the basic problem with making python-3 unstable, in my opinion, is that it would be a way of lying to our users. Basically, the python team finds that python3 on Gentoo systems works just fine by itself, and more and more python packages can work just fine with it. It's perfectly sane to have applications on Gentoo built to work with Python 3, and those applications are supported by the python team the same way python-2-based applications are supported. Furthermore, python upstream have set a schedule for Python 3 to be accepted after five or more years of availability. The need to have both available from systems is actively recognized and supported. Fact is, chances are we need to migrate our systems over to Python 3 at some point. Some parts of the ecosystem support it already, some parts will take more time, and some parts will eventually be obviated because they are never updated. I'm not sure how you see this transition happening. It seems to me like there will always be a time when python2 and python3 are both available, and we have some packages that need the former, and some packages that need the latter. You can choose to delay that moment, but I don't see how it makes everyone's lives better in the long term. On the other hand, by distributing python3 from stable now, in a controlled manner where it's never the default (and perhaps can be prohibited or actively discouraged from ever being made the default, in some way), we make it much easier to smooth the transition. For example, I generally run stable systems and run the test suites, such that python packages I install and that are marked to support python 3 get test suites run against both versions. I understand that it might feel pointless to distribute python3 in space-constrained scenarios such as release media, and I would tend to agree, but I don't think making python-3 unstable is the best solution to this problem.
(In reply to comment #22) > I was not suggesting to change the dependency resolution algorithm for the > package manager, I was suggesting that it might be possible to change the > specific dependencies in the portage ebuild in some way that they can be > satisfied without pulling in python-3. > Looking at portage-2.2.0_alpha32.ebuild the ebuild should not be pulling python-3 when USE is set to "python2 -python3". I cced Portage devs so they can verify. I think this means we should just make sure the python3 use flag is never enabled when building stages.
(In reply to comment #23) > (In reply to comment #22) > > I was not suggesting to change the dependency resolution algorithm for the > > package manager, I was suggesting that it might be possible to change the > > specific dependencies in the portage ebuild in some way that they can be > > satisfied without pulling in python-3. > > > > Looking at portage-2.2.0_alpha32.ebuild the ebuild should not be pulling > python-3 when USE is set to "python2 -python3". I cced Portage devs so they can > verify. I think this means we should just make sure the python3 use flag is > never enabled when building stages. Petteri, as long as you don't expect the releng team to use package.use files or to add -python3 to make.conf, there won't be any objections from releng. One of the base arguments in all this is that releng wants the stages to reflect the tree status, so when someone changes the tree status, one is changing what is built with the stages.
(In reply to comment #24) > as long as you don't expect the releng team to use package.use files or to add > -python3 to make.conf, there won't be any objections from releng. It would require package.use.force given that stage1 always does USE="-*". This can be done globally in profiles/base/, however, a possible alternative would be to put settings like this in a sub-profile that's intended for stage builds.
(In reply to comment #25) > (In reply to comment #24) > > as long as you don't expect the releng team to use package.use files or to add > > -python3 to make.conf, there won't be any objections from releng. > > It would require package.use.force given that stage1 always does USE="-*". This > can be done globally in profiles/base/, however, a possible alternative would > be to put settings like this in a sub-profile that's intended for stage builds. As discussed on IRC turning on python2 by default should be enough. This can be a simple base/package.use change or IUSE default in the ebuild itself. However this won't solve the problem if Portage is not the only thing pulling in python. In the longer term really the python team should start moving towards a solution like ruby has with RUBY_TARGETS and then it's a matter of controlling the USE_EXPAND settings to make sure what python versions get installed.
The council feels there is nothing to gain from interfering on this issue. We defer to Release Engineering and consider their vote binding.
The RelEng team maintains that this bug should be closed as WONTFIX. Jeroen / Alex / Dirkjan: to avoid the complaints the last time I closed the bug, can I close it or do you want to reassign the bug to yourselves and leave release out of it?
Feel free to close it, fine with me!
RESO GENTOOSUX
