[gentoo-dev] Re: Python 3.1: Stabilization and news item
George Prowse posted on Fri, 26 Mar 2010 17:53:31 + as excerpted: On 26/03/2010 17:43, Dale wrote: It's not faith, its reality. There will be some people that don't subscribe to this list that will do what is above. This IS the reason I subscribed to this list. I wanted to know what the devs were doing under the hood that would lead me to screw up my system. It's amazing how much fewer problems I have had since I started watching this list. Also, if python3 is marked as stable, people will assume it is safe to switch to. That's what stable means. It's Gentoo and naturally users are like magpies, they like everything newest, highest and shiniest. Hmm... looking closely, I think it's myself I see in that mirror! =:^) Pretty apt description, I think, tho I don't suppose it's entirely accurate for stale users or they'd find it just that. I certainly do. Take baselayout-2/openrc for instance; /how/ many years stale is baselayout-1 now? -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
2010-03-23 20:57:33 Jonathan Callen napisał(a): On 03/23/2010 03:13 PM, Arfrever Frehtes Taifersar Arahesis wrote: I'm attaching updated news item, which will be committed soon. A couple grammar issues: -modules, which support both Python 2 and Python 3, are installed for both -active version of Python 2 and active version of Python 3, when both Python 2 -and Python 3 are installed. +modules that support both Python 2 and Python 3 are installed for both the +active version of Python 2 and the active version of Python 3 when both +Python 2 and Python 3 are installed. I have locally applied these changes some hours ago, but I'm attaching updated news item so that it can be reviewed easier. If there are no additional, new suggestions, then the news item will be committed tomorrow. -- Arfrever Frehtes Taifersar Arahesis Title: Python 3.1 Author: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org Content-Type: text/plain Posted: 2010-03-24 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =dev-lang/python-3.1* Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so Python 2 still needs to be installed. You can benefit from having Python 3 installed without setting Python 3.1 as main active version of Python. Currently you should not set Python 3.1 as main active version of Python. When setting it becomes recommended, a separate news item will be created to notify users. Although Python 3.1 should not be set as main active version of Python, you should run python-updater after installation of Python 3.1. By default, modules that support both Python 2 and Python 3 are installed for both the active version of Python 2 and the active version of Python 3 when both Python 2 and Python 3 are installed. It is recommended to use a UTF-8 locale to avoid potential problems. Especially C and POSIX locales are discouraged. If locale has not been explicitly set, then POSIX locale is used, so you should ensure that locale has been set. Problems occurring only with non-UTF-8 locales should be reported directly to upstream developers of given packages. See http://www.gentoo.org/doc/en/utf-8.xml for more information about UTF-8. signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Python 3.1: Stabilization and news item
William Hubbs posted on Wed, 24 Mar 2010 13:03:34 -0500 as excerpted: If users do not want python-3 on their systems, that is what /etc/portage/package.mask is for. I think pretty much everyone agrees with that. What we're debating is whether the stabling news item should specifically mention package.mask as an option before it goes stable. Fortunately or unfortunately, despite the stated Gentoo policy of documentation but not hand holding, stable Gentoo users are in fact used to having a bit of extra hand-holding and have come to expect it. While the generally given reason for said hand-holding is that we're simply avoiding the flood of bugs we'd otherwise get, and arguably that doesn't apply in this case (arguably, because there are still and will be new python dependency bugs that this will trigger), it's an expectation stable users have come to have, and failing to specifically mention the package.mask option violates this expectation. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Python 3.1: Stabilization and news item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/23/2010 03:13 PM, Arfrever Frehtes Taifersar Arahesis wrote: I'm attaching updated news item, which will be committed soon. A couple grammar issues: - -modules, which support both Python 2 and Python 3, are installed for both - -active version of Python 2 and active version of Python 3, when both Python 2 - -and Python 3 are installed. +modules that support both Python 2 and Python 3 are installed for both the +active version of Python 2 and the active version of Python 3 when both +Python 2 and Python 3 are installed. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkupHS0ACgkQOypDUo0oQOp+3ACdFdADMtd40bbzDO+/8wUgefZb 7gEAnj/SNtfF3/0FAXNw/ffRki4vjE7o =cCyr -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On 03/10/10 11:36, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-08 22:28:16 William Hubbs napisał(a): On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote: No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage echo dev-lang/python ~* /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency likedev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the According to this, we can fix all of the dependencies in the tree then stabilize python3 without having any issues, so I would vote for this route, because it still oinsures that the stable tree will work together. Almost everybody has at least 1 package installed which supports both Python 2 and Python 3 and depends on dev-lang/python without version specification, so Python 3 would be pulled into dependency graph, so fixing of dependencies doesn't need to block stabilization of Python 3. What about introducing a python3 USE flag? Seems like that would keep everybody happy. --Ravi
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On Wed, Mar 10, 2010 at 9:04 PM, Jacob Godserv jacobgods...@gmail.com wrote: The problem here, I think, is everyone has their opinion about what it means for something to go stable, and I haven't seen more than one or two references to what has been predetermined as policy for stabilization. I think we should do a little less debating over personal opinions (which is a hot topic, apparently) and more about how Gentoo guidelines determine what can go stable. If the guidelines don't cover this, then they ought to be fixed. The opinions of most of the people in this thread are not directly relevant anyway. The maintainer gets to decide when to file a stablereq bug for their package and the arch teams to get to decide whether to mark something stable on their arch or not. So someone just make a decision and move forward; we will never reach consensus here (and we should not be trying to reach one anyway.) -A -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Hi, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org: All problems, which were blocking stabilization of Python 3, have been fixed. Stabilization of Python 3.1.2 is currently scheduled on 2010-04-19. I'm attaching the news item for Python 3.1. Will add my comments for the whole thread here: As far as I can see, there is no danger to any program as long as Python 3 is not set as system python. As soon as the request is filed I will install it on my stable systems and try it...for some weeks to be absolutely sure nothing happens. Then I have nothing against marking it stable on x86 and will do so. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
2010-03-08 22:28:16 William Hubbs napisał(a): On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote: No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage echo dev-lang/python ~* /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the According to this, we can fix all of the dependencies in the tree then stabilize python3 without having any issues, so I would vote for this route, because it still oinsures that the stable tree will work together. Almost everybody has at least 1 package installed which supports both Python 2 and Python 3 and depends on dev-lang/python without version specification, so Python 3 would be pulled into dependency graph, so fixing of dependencies doesn't need to block stabilization of Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On 10 March 2010 18:36, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Almost everybody has at least 1 package installed which supports both Python 2 and Python 3 and depends on dev-lang/python without version specification, so Python 3 would be pulled into dependency graph, The problem is that we want to prevent that from happening. Or at the very least advise our users that they should mask python-3* unless they want it to be pulled in. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On Wed, Mar 10, 2010 at 11:43:04PM +0100, Ben de Groot wrote: On 10 March 2010 18:36, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Almost everybody has at least 1 package installed which supports both Python 2 and Python 3 and depends on dev-lang/python without version specification, so Python 3 would be pulled into dependency graph, The problem is that we want to prevent that from happening. Or at the very least advise our users that they should mask python-3* unless they want it to be pulled in. If someone has a package that truly works with either python 2 or 3, what is the harm in automatically pulling in python 3 and installing the package for both python 2 and 3? As long as pulling in python-3 doesn't change the system's default python interpretor I don't see a problem with having them both installed. William pgpnrRLKYVc4i.pgp Description: PGP signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On 11 March 2010 01:25, William Hubbs willi...@gentoo.org wrote: If someone has a package that truly works with either python 2 or 3, what is the harm in automatically pulling in python 3 and installing the package for both python 2 and 3? As long as pulling in python-3 doesn't change the system's default python interpretor I don't see a problem with having them both installed. I've seen enough python-3 specific bugs to know it is not without problems. It's a waste of time and resources for something that is not ready to be used anyway. While it can be argued that that is what our testing branch is for, it is certainly not something that should be pushed to stable users. Even if it would be just dead weight, it is not something we should wish for. It is bloat, it is unnecessary, and causes more problems than that it solves. Why should users have to compile multiple python versions, if they only use one anyway? Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On Thu, Mar 11, 2010 at 02:24:46AM +0100, Ben de Groot wrote: On 11 March 2010 01:25, William Hubbs willi...@gentoo.org wrote: ??If someone has a package that truly works with either python 2 or 3, ??what is the harm in automatically pulling in python 3 and installing ??the package for both python 2 and 3? ??As long as pulling in python-3 doesn't change the system's default ??python interpretor I don't see a problem with having them both ??installed. I've seen enough python-3 specific bugs to know it is not without problems. It's a waste of time and resources for something that is not ready to be used anyway. While it can be argued that that is what our testing branch is for, it is certainly not something that should be pushed to stable users. What does upstream say about python 3.1? Are they calling it stable? Yes, it is incompatible with python-2, but, it is set up so both can be on a system at the same time. I'm no expert on python, but I think even upstream has python deliberately set up that way. Even if it would be just dead weight, it is not something we should wish for. It is bloat, it is unnecessary, and causes more problems than that it solves. Why should users have to compile multiple python versions, if they only use one anyway? If they are only using python-2 and all of the packages they use only work with python-2, then the dependencies of the packages should be fixed to reflect that. Even if python-3 is stable and the dependencies of the packages they have say that they only support python-2 python-3 will not be on their systems. Someone compared pythohn to gcc earlier in this thread, but I'm not sure that is a fair comparison. AFAIK, gcc is not slotted by upstream, and python is. I think that makes a difference in how we handle it. William pgptqhpeP9Ks3.pgp Description: PGP signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
The problem here, I think, is everyone has their opinion about what it means for something to go stable, and I haven't seen more than one or two references to what has been predetermined as policy for stabilization. I think we should do a little less debating over personal opinions (which is a hot topic, apparently) and more about how Gentoo guidelines determine what can go stable. If the guidelines don't cover this, then they ought to be fixed. -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
Zeerak Mustafa Waseem wrote: On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote: A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. +1 on that. If your program is only tested with python-2 or has regressions with python-3 (e.g. performance loss), a maintainer can and should mark that package as python-2 only. For new systems, the only must have python user i can think of is portage. And that has an explicit USE=python3 and as Zac outlined takes DEPEND-pains to ensure python-2.* is pulled in if available. So you're starting with python-2.* and every program not explicitly pulling in python-3.* should be happy with that. I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. You're actually damning most of the tree to be ~arch, if that's the criterion for stable. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. These are contradicting statements. Repoman will and should kill anyone attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if that ebuild is to be marked stable, too. So b/c i still can't understand what's so horrible about python-3 going into stable (even if p.mask'ed, if that's the consensus), my vote goes to mark it stable already. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
Matti Bickel dixit (2010-03-08, 10:39): A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. +1 on that. If your program is only tested with python-2 or has regressions with python-3 (e.g. performance loss), a maintainer can and should mark that package as python-2 only. For new systems, the only must have python user i can think of is portage. And that has an explicit USE=python3 and as Zac outlined takes DEPEND-pains to ensure python-2.* is pulled in if available. So you're starting with python-2.* and every program not explicitly pulling in python-3.* should be happy with that. I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. You're actually damning most of the tree to be ~arch, if that's the criterion for stable. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. These are contradicting statements. Repoman will and should kill anyone attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if that ebuild is to be marked stable, too. So b/c i still can't understand what's so horrible about python-3 going into stable (even if p.mask'ed, if that's the consensus), my vote goes to mark it stable already. Sorry guys if I missed something crucial in this lengthy thread, but from what I'm understanding: if python-3 goes stable (and unmasked): - it is a separate, slotted version - it generally shouldn't get pulled in (current portage non-greedy behaviour on slots) - if it does get pulled in by, say, and old portage version, or a package with badly defined deps, it shouldn't do any harm because it will just sit quietly in its slot and old packages will still compile/run against (already installed) python-2.x or not? PS. one thing I realize I may be missing is the /usr/bin/python symlink and the /usr/bin/python-wrapper to which it points. Will the default change to python31 upon python-3 installation? best, -- [a] pgpQJOsKfpDsQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote: No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage echo dev-lang/python ~* /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the According to this, we can fix all of the dependencies in the tree then stabilize python3 without having any issues, so I would vote for this route, because it still oinsures that the stable tree will work together. William pgpNaLSlmgYgl.pgp Description: PGP signature
[gentoo-dev] Re: Python 3.1: Stabilization and news item
On Sun, 7 Mar 2010 12:11:47 -0500 Mark Loeser halc...@gentoo.org wrote: Has QA given their blessing to this? Absolutely not. Its actually the opposite. Until 90+% of the tree just works with the new version of python, it should not be stabilized. The stable tree should all Just Work together. Stabilizing python-3 at this point would be the equivalent of me stabilizing gcc-4.5 after its been in the tree for a few months and nothing else works with it. Sure, gcc works just fine, but it can't compile half of the tree. I don't think it's the same. This is like saying we can't stabilize qt-4 because half the tree is (was) qt-3. These packages are likely never going to work with the newer version, that's why it's slotted and now we have an admittedly impressive framework for making sure python-2 programs get python-2 and python-3 get python-3. Another example from my camp is wxGTK. Half the stuff in the tree (even now) doesn't work with 2.8, so we introduced a system where packages would get the version they needed, while users could use whatever version they wanted independent of portage. 2.8 has been stable for over 3 years now. I've been messing with the new python stuff this past week and I'm sold. If you recall I was one of the people completely against the idea last time this topic came up. I hope everyone can see that this is a terrible idea and of no use to our stable users. If a stable user really needs Python-3, they will have the technical ability to unmask it and use it properly. A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. Are we really saying that no python-3-based package can go into stable until 90% of the tree is python-3? That's like, 5 years from now, if ever. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote: On Sun, 7 Mar 2010 12:11:47 -0500 Mark Loeser halc...@gentoo.org wrote: Has QA given their blessing to this? Absolutely not. Its actually the opposite. Until 90+% of the tree just works with the new version of python, it should not be stabilized. The stable tree should all Just Work together. Stabilizing python-3 at this point would be the equivalent of me stabilizing gcc-4.5 after its been in the tree for a few months and nothing else works with it. Sure, gcc works just fine, but it can't compile half of the tree. I don't think it's the same. This is like saying we can't stabilize qt-4 because half the tree is (was) qt-3. These packages are likely never going to work with the newer version, that's why it's slotted and now we have an admittedly impressive framework for making sure python-2 programs get python-2 and python-3 get python-3. Another example from my camp is wxGTK. Half the stuff in the tree (even now) doesn't work with 2.8, so we introduced a system where packages would get the version they needed, while users could use whatever version they wanted independent of portage. 2.8 has been stable for over 3 years now. I've been messing with the new python stuff this past week and I'm sold. If you recall I was one of the people completely against the idea last time this topic came up. I hope everyone can see that this is a terrible idea and of no use to our stable users. If a stable user really needs Python-3, they will have the technical ability to unmask it and use it properly. A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. Are we really saying that no python-3-based package can go into stable until 90% of the tree is python-3? That's like, 5 years from now, if ever. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. As it has been said, should a user need python 3 they most likely know what they're doing and keywording it shouldn't be a problem. So my vote goes towards stabilizing the applications that depend on python three, in their due time, and keeping python-3 keyworded. -- Zeerak Waseem pgpeDiZalgPPO.pgp Description: PGP signature
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Petteri Räty posted on Sun, 07 Mar 2010 20:25:07 +0200 as excerpted: n my opinion python-3 should go stable when there's enough ebuilds needing it as a dependency. It doesn't need to nowhere near 90% of python packages in the tree. Indeed. Given that it's slotted and (barring bugs) won't interfere, and would need to be stabilized before another package requiring it can be stabilized, that would seem to be the point at which we need to worry about stabilization -- when other package stabilization is being blocked because they require python-3, which isn't yet stable. But until that point... and I've seen nothing even pointed out for discussion as an example of such a package yet... I don't see that it needs to be (or should be) in stable at all. When such packages appear, /then/ we can discuss if the time is right w.r.t. everything else (non- interfering slots, etc, vs. popularity of depending package(s)). Until then, I just don't see the purpose or point in it. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Ben de Groot posted on Thu, 04 Mar 2010 23:56:46 +0100 as excerpted: Personally I am recommending people to locally mask python-3*. I think we should consider to add it to our package.mask, unless we can find some other solution. I am not against it being marked stable, but I am against having it pulled in on systems that don't need it. ++ I've package masked python3 here. There are some things I like being leading, even bleeding edge on. Python isn't one of them. When some package I want to merge wants python-3 and isn't going to take python-2 (or if I decide I want to learn python, since one might as well learn 3 at this point if they're learning), /then/ I'll consider unmasking it. Until then, or at least for quite some time yet if that doesn't happen, there's no reason I need the additional complications of python-3 problems on my system. I'd say the same goes for most users. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted: On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. Won't emerge -aNuD pull it in anyway, even in a new slot, since portage says it can use it? I know I use that, so I'm always updated all the way thru the system, not just at the leaves. I know it did for me on ~arch, the reason I have it masked. So, as has already been proposed, why not stable it, while at the same time masking it, with an appropriate masking message explaining that it is stable, but we're just preventing the majority of folks from pulling it in, since they don't need it yet? That way, those who want/need it can unmask it the usual way, and everyone can continue as the were... at least until the first package requiring python-3 only comes along. Realistically, how long is that likely to be? Otherwise, what about a news item saying it's to be stabilized, and warning people that don't think they want or need it to put it in package.mask themselves? That would seem to be about the best compromise I can see ATM. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Python 3.1: Stabilization and news item
On Fri, 5 Mar 2010 13:37:28 +0100 Ben de Groot yng...@gentoo.org wrote: On 5 March 2010 12:24, Zac Medico zmed...@gentoo.org wrote: It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. That means we would need to fix all packages that depend on python to use this style of dependency notation. Or do some eclass magic with NEED_PYTHON for example. Or PYTHON_DEPEND? http://www.gentoo.org/proj/en/Python/developersguide.xml -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On 03/05/2010 11:26 AM, Duncan wrote: Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted: On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. Won't emerge -aNuD pull it in anyway, even in a new slot, since portage says it can use it? I know I use that, so I'm always updated all the way thru the system, not just at the leaves. No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage echo dev-lang/python ~* /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the dependency graph. -- Thanks, Zac
