[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
Arfrever Frehtes Taifersar Arahesis posted on Tue, 23 Mar 2010 16:37:34 +0100 as excerpted: > 2010-03-22 22:12:54 Jacob Godserv napisał(a): >> On Sat, Mar 20, 2010 at 10:11, Arfrever Frehtes Taifersar Arahesis >> wrote: >> > 2010-03-20 01:51:44 Duncan napisał(a): >> >> So let's just recognize that it's not a perfect situation, create a >> >> news item saying that python-3 will soon (give a date) be unmasked, >> >> and suggest that users not needing it may wish to package.mask it >> >> themselves, with a link to documentation with specific instructions >> >> and a bit more detail on why they might wish to mask it and under >> >> what circumstances they might not. >> >> >> >> I'd suggest an unmasking date 30 days after the release of the news >> >> item. >> > >> > Python 3 is not masked. The discussion is about stabilization. >> >> Duncan's comments still apply, though, right? What's against writing a >> news item about stabilizing Python? > > There is already a thread about news item: > http://archives.gentoo.org/gentoo-dev/ msg_814e67764c17f88bde94f22e9a392e4f.xml (link wrapped) But that doesn't mention that users may wish to package.mask it, to avoid having it on their systems at all. That's what /I/ was suggesting in /this/ thread, that a news item (presumably that one) should mention the package.mask option. That really does seem to be about the best compromise, given the situation as described so well in this thread. -- 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: Packages pulling in python-3*, also they dont require it
2010-03-22 22:12:54 Jacob Godserv napisał(a): > On Sat, Mar 20, 2010 at 10:11, Arfrever Frehtes Taifersar Arahesis > wrote: > > 2010-03-20 01:51:44 Duncan napisał(a): > >> So let's just recognize that it's not a perfect situation, create a news > >> item saying that python-3 will soon (give a date) be unmasked, and suggest > >> that users not needing it may wish to package.mask it themselves, with a > >> link to documentation with specific instructions and a bit more detail on > >> why they might wish to mask it and under what circumstances they might not. > >> > >> I'd suggest an unmasking date 30 days after the release of the news item. > > > > Python 3 is not masked. The discussion is about stabilization. > > Duncan's comments still apply, though, right? What's against writing a > news item about stabilizing Python? There is already a thread about news item: http://archives.gentoo.org/gentoo-dev/msg_814e67764c17f88bde94f22e9a392e4f.xml -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On Sat, Mar 20, 2010 at 10:11, Arfrever Frehtes Taifersar Arahesis wrote: > 2010-03-20 01:51:44 Duncan napisał(a): >> So let's just recognize that it's not a perfect situation, create a news >> item saying that python-3 will soon (give a date) be unmasked, and suggest >> that users not needing it may wish to package.mask it themselves, with a >> link to documentation with specific instructions and a bit more detail on >> why they might wish to mask it and under what circumstances they might not. >> >> I'd suggest an unmasking date 30 days after the release of the news item. > > Python 3 is not masked. The discussion is about stabilization. Duncan's comments still apply, though, right? What's against writing a news item about stabilizing Python? -- 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: Packages pulling in python-3*, also they dont require it
2010-03-20 01:51:44 Duncan napisał(a): > So let's just recognize that it's not a perfect situation, create a news > item saying that python-3 will soon (give a date) be unmasked, and suggest > that users not needing it may wish to package.mask it themselves, with a > link to documentation with specific instructions and a bit more detail on > why they might wish to mask it and under what circumstances they might not. > > I'd suggest an unmasking date 30 days after the release of the news item. Python 3 is not masked. The discussion is about stabilization. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
2010-03-20 13:51:37 Peter Hjalmarsson napisał(a): > I have a question related to this: > > If I have package X which supports python2 and python 3, and I install > it without python3 installed it will only install python2-files > (i.e. /usr/lib/python2.x/*), right? > What happens if I later install packages Y that is only python3, and > relies on the python3 parts of package X? Can this happen and how will > the PM handle that (reemerge package X installing the python3 parts or > fail to compile package Y due to missing python module)? As the news item says, you should run python-updater after installation of Python 3.1. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
I have a question related to this: If I have package X which supports python2 and python 3, and I install it without python3 installed it will only install python2-files (i.e. /usr/lib/python2.x/*), right? What happens if I later install packages Y that is only python3, and relies on the python3 parts of package X? Can this happen and how will the PM handle that (reemerge package X installing the python3 parts or fail to compile package Y due to missing python module)?
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/20/2010 02:56 AM, Jean-Marc Hengen wrote: > Duncan wrote: >> ... > > ++ - I can only add the saying "With freedom comes great responsibility.". > > Maybe the python herd could maintain a little status page which covers > informations like: > - Estimated python 3 compatibility in respect to the packages in the > main tree. That would be easy enough to generate from dependencies. Surely there are some dependencies that need to be updated, but that shouldn't be much work. For example, I've already updated the cracklib and libxml2 deps to indicate lack of python3 support. > - Recommendations if installing makes sense or not (e.g. package X gains > feature Y with python 3). > - Recommendations if setting python 3 as system engine makes already > sense or not. > This way gentoo can give its users the tools needed to make a good > decision if python 3 makes sense on his system. For me as a user I need > more time to study if an action makes sense than implementing said > action (e.g. locally masking python 3 - It would not be the first time > masking a package). If one isn't into python, it gets even more complicated. I would advise people to go ahead and install it as long as they can spare a little disk space and cpu time. Anybody who is tight on those resources should feel free to mask it (and the dependency resolver will certainly notify you if this is not feasible in your case). Honestly, I don't see a need for lots of data analysis here, but maybe some people just like that kind of thing. -- Thanks, Zac
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
fre 2010-03-19 klockan 05:13 -0500 skrev Dale: > Because, when I installed gcc 4.3, I could then unmerge the old gcc. > That's why I didn't complain about that. With python, we still have to > have the current version plus the new version which is not being used at > all. > That was if you did not use qemu that did *not* compile or run with a gcc never then gcc-3 for a couple of years... Also search for "gcc-porting" in b.g.o and guess what: there are many packages that fits this description for gcc, qemu was just a special case since for it it actually took YEARS before upstream released a version that worked with gcc-4, most other packages is often easier to patch (since it is mostly compile-time brokenness related to headers or other "small" fixes) and our awesome toolchain guys helps fixing it up before it hits ~arch.
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/19/2010 08:26 PM, Alec Warner wrote: On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziaras wrote: You guys always make easy decisions so complicated. :P Masking a package is not complicated. Yes, that's why all the heated debates about Python 3 exist, because it's all so simple. It *is* simple, but you don't want it to be.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
Duncan wrote: > ... ++ - I can only add the saying "With freedom comes great responsibility.". Maybe the python herd could maintain a little status page which covers informations like: - Estimated python 3 compatibility in respect to the packages in the main tree. - Recommendations if installing makes sense or not (e.g. package X gains feature Y with python 3). - Recommendations if setting python 3 as system engine makes already sense or not. This way gentoo can give its users the tools needed to make a good decision if python 3 makes sense on his system. For me as a user I need more time to study if an action makes sense than implementing said action (e.g. locally masking python 3 - It would not be the first time masking a package). If one isn't into python, it gets even more complicated. J_M
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
Dale posted on Fri, 19 Mar 2010 05:13:48 -0500 as excerpted: > Ciaran McCreesh wrote: >> On Fri, 19 Mar 2010 04:23:31 -0500 >> Dale wrote: >> It's being installed because it's a dependency of something you use. Replace Python with any other library and we wouldn't be having this discussion. >>> OK. Right now, as you type this, what package depends on python-3 and >>> won't work with python-2? Anything at all? If it is nothing, then >>> why install it? >>> >> And that's where you're making the mistake: you're treating Python as >> being different from every other package. >> >> In every other case, you want things to be using the newest version of >> a slotted package where possible. Why aren't you complaining that you >> were forced to install gcc 4.3 and 4.1 when 3.4 worked just fine? >> >> > Because, when I installed gcc 4.3, I could then unmerge the old gcc. > That's why I didn't complain about that. With python, we still have to > have the current version plus the new version which is not being used at > all. I had to pick somewhere to reply, and this seemed as good a place as any, as it does give me a jumping off point... It seems to me Ciaran is correct in one point, at least: python-3.x /is/ different than most such major updates (but then again, each such major update tends to have its unique points). That's why this huge discussion. It also seems to me that, due to the resolver and dependency specifier technology on the one side, the practicalities of running one's system with least complication (thus, most people /not/ wanting the normal update as soon as available/stable, in this /special/ case) on another, political correctness (the problem with just masking it in base and being done with it) on a third, and the number of packages to update to specific dependencies much like portage's, should that be chosen, on the fourth, we're pretty much surrounded with unpleasant alternatives that /are/ going to be something of an issue for /some/, no matter which is chosen. Again, thus the huge discussion. So what can be done besides continuing to spin wheels as we are? What's the least painful, yet still practical, alternative, all factors considered? Here's one that I'll admit isn't perfect, but none are. Yet this one seems the best way forward to me, given the alternatives. First, let's step back a moment and remember a defining characteristic of Gentoo, that we give the users both freedom and responsibility for their own systems, and have never made excuses for that fact. Second, let's remember that we /do/ have the news feature now, so at least there's a way to communicate a warning about such things. After that, it's generally up to the user, as, ultimately, it seems likely to be here. But we /can/ warn them using a news item, first, and given that, we /should/. So let's just recognize that it's not a perfect situation, create a news item saying that python-3 will soon (give a date) be unmasked, and suggest that users not needing it may wish to package.mask it themselves, with a link to documentation with specific instructions and a bit more detail on why they might wish to mask it and under what circumstances they might not. I'd suggest an unmasking date 30 days after the release of the news item. Yes, that's not going to get everyone before it happens, but the news item will be there after that for those what want to read it, and if people aren't doing that --ask or --pretend before they go doing their updates, especially if they're going a month or more between updates, well... Worst-case they get a py3k sitting there basically unused, and a few extra builds for some period, until such time as py3k is considered stable and popular enough to be the system default. This to me seems the best of painful choices. Down side, it's forcing every user to fiddle with their masks or decide not to. Three up sides: (1) At least with the news item they get some warning and can put the mask in place ahead of time. (2) We're simply relying on one of the best features of Gentoo, the one giving the user both the freedom and responsibility to manage his own system. (3) It gives us a way to actually move forward, /now/, using our current tools, without continuing the debate /forever/. Can anyone shoot holes in this any worse than the other proposals? Let's give our users the warning they need, and treat them like the adults Gentoo has always claimed to respect them as. What they do with it after that is up to them. -- 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: Packages pulling in python-3*, also they dont require it
On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziaras wrote: > On 03/19/2010 10:57 AM, Ciaran McCreesh wrote: >> >> On Fri, 19 Mar 2010 03:54:28 -0500 >> Dale wrote: >>> >>> Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Groot wrote: > Because it is extremely useless to the great majority of users. > Most packages in the tree are useless to the great majority of users. >>> >>> Which is why most users don't install everything. I have about 1000 >>> packages installed here. The packages installed are either something >>> I use or a dependency of something I use. What exactly is this being >>> installed for again? If nothing depends on it, there is no need to >>> have it. >> >> It's being installed because it's a dependency of something you use. >> >> Replace Python with any other library and we wouldn't be having this >> discussion. > > It's weird that we have this discussion, that's true. Why don't you guys > simply do what you did before when Qt3 was still in the tree? Qt3 > applications depended on x11-libs/qt:3, Qt4 ones on x11-libs/qt:4 (before > the Qt4 ebuild split). Using your example, some applications would have had to exist that could use either Qt3 or Qt4, so a greedy SLOT matcher would pull in Qt4 (and to be equal to the python case, portage would have to build two copies of all the binaries, one linked against qt3 and one linked against qt4, because python.eclass does something similar, but I digress.) > > It seems very obvious and straightforward that the same applies here. And if > a package offers both Python 2 and Python 3 compatibility, it should depend > on whatever the upstream of that package considers best. When choosing dependencies you want to maximize flexibility (because users like it for some reason). So we chose 'dev-lang/python' because typically any ole' version of python will work. If we hardcoded everything upstream 'recommended' (many upstreams don't make such recommendations either, which puts us in an interesting situation) it means when our users want to do something upstream does not 'recommend' they have to do a bunch of work like have a custom overlay just so they can changed a DEPEND string that should not have been so specific in the first place. Amusingly this very thing happened to me at work; a bunch of scripts depend on python but their dependencies are 'python2.4' and Ubuntu Lucid has no python2.4 (it ships with 2.6). Now I get to rewrite all the dependencies in all the debs to depend on 'python < 3' instead of 'python2.4.' Most of this work would have been unnecessary had the dependencies just been a bit more flexible. > > Also, we had a "qt" and "qt4" USE flag before. Why not "python" and > "python3" flags? That's an additional way ebuilds can choose deps. > > You guys always make easy decisions so complicated. :P Masking a package is not complicated. > > > I just want to give props to Arfrever for getting Python3 into the tree so quickly. Thanks for all your work on this. -A
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/19/2010 10:57 AM, Ciaran McCreesh wrote: On Fri, 19 Mar 2010 03:54:28 -0500 Dale wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Groot wrote: Because it is extremely useless to the great majority of users. Most packages in the tree are useless to the great majority of users. Which is why most users don't install everything. I have about 1000 packages installed here. The packages installed are either something I use or a dependency of something I use. What exactly is this being installed for again? If nothing depends on it, there is no need to have it. It's being installed because it's a dependency of something you use. Replace Python with any other library and we wouldn't be having this discussion. It's weird that we have this discussion, that's true. Why don't you guys simply do what you did before when Qt3 was still in the tree? Qt3 applications depended on x11-libs/qt:3, Qt4 ones on x11-libs/qt:4 (before the Qt4 ebuild split). It seems very obvious and straightforward that the same applies here. And if a package offers both Python 2 and Python 3 compatibility, it should depend on whatever the upstream of that package considers best. Also, we had a "qt" and "qt4" USE flag before. Why not "python" and "python3" flags? That's an additional way ebuilds can choose deps. You guys always make easy decisions so complicated. :P