Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Alec Warner wrote: On Thu, Mar 18, 2010 at 1:27 PM, Ben de Grootyng...@gentoo.org wrote: On 18 March 2010 20:24, Fabian Groffengrob...@gentoo.org wrote: On 18-03-2010 20:20:02 +0100, Thomas Sachau wrote: There are 2 ways to fix this issue: -fix the dependency string for those packages (including the lines in distutils.eclass) or (since Arfrever claims current portage behaviour is wrong) -change portage behaviour to be satisfied with a python slot and to not require other slots. Since the last option will take time in any case, I guess the first option is the best to achieve the desired goal: make sure Python 3 stays as far away as possible from any system that doesn't need it. And the best way to do that is to package.mask it. The maintainer has chosen not to mask it in gentoo-x86, which means users are empowered to mask it locally and everyone who is complaining about getting python3 installed on their system should mask it locally. This is how users work around other defaults in the tree they don't agree with (USE flags, KEYWORDS, etc.) I don't get why this is a big deal at all or why people are unable to solve this themselves. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer I think this is because people that use Gentoo do so because it doesn't install things they don't need. Why install a package that is used by no other package? It's pointless. I would also add, if it gets installed and is used by no other package, --depclean should remove it. Putting it in package.mask locally is sort of silly in my opinion. There will come a day, maybe way off in the future, that something will need it. Then you have to edit the file again so portage can install it. This just seems to be adding either more work or unneeded packages. This is a users $0.02 worth. Dale :-) :-)
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/19/2010 12:15 AM, Dale wrote: I think this is because people that use Gentoo do so because it doesn't install things they don't need. Why install a package that is used by no other package? It's pointless. I would also add, if it gets installed and is used by no other package, --depclean should remove it. Putting it in package.mask locally is sort of silly in my opinion. There will come a day, maybe way off in the future, that something will need it. Then you have to edit the file again so portage can install it. I guess what you want is an emerge --avoid-new-slots-whenever-possible option. You might also want it to check for cases in which pulling in a new slot will allow you to remove an older slot (that will require some additional work). Having options like those would be really super, but I don't think using package.mask to do it will be so awful. -- Thanks, Zac
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On Thu, Mar 18, 2010 at 06:29:56PM +0200, Markos Chandras wrote: Dear fellow developers, A new project is about to start so I am requesting your feedback The primary goal of the Proxy Maintainers[1] project is to create and maintain relationships between developers and users in order to ensure packages in the Gentoo tree stay up to date. This involves a few main tasks: [...] 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in Gentoo bugzilla?I think the latter is the best IMO, the best route would be to start with-in Gentoo Bugs, then slowly move each contributor to a proxy-maintainer overlay. This overlay would not have a review process for ebuilds, meaning that every contributor that has passed the first stage (by submitting a few ebuilds in bugzilla) will be granted access. that way users will: * get experience on actually committing stuff to a tree * learn how to use tools like repoman and git (think of the future ;)) it will also be better for us. moving packages from the overlay to tree will be simpler, also tracking versions and package status will be easier. 2) I think an email alias is not needed We can monitor maintainer-wanted/- needed alias if needed. What do you think? If we go with the new overlay, I think we'll need an alias where the users can ask for help and talk about their packages. 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that the specific bug is already taking by another developer and that somebody is working on it. So marking a bug with a keyword e.g. PROXY might be useful. Thats not a bad idea. Another solution would be to assign the bugs to proxy-maintain...@g.o. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpSloZtxpV78.pgp Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Groot yng...@gentoo.org 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Zac Medico wrote: On 03/19/2010 12:15 AM, Dale wrote: I think this is because people that use Gentoo do so because it doesn't install things they don't need. Why install a package that is used by no other package? It's pointless. I would also add, if it gets installed and is used by no other package, --depclean should remove it. Putting it in package.mask locally is sort of silly in my opinion. There will come a day, maybe way off in the future, that something will need it. Then you have to edit the file again so portage can install it. I guess what you want is an emerge --avoid-new-slots-whenever-possible option. You might also want it to check for cases in which pulling in a new slot will allow you to remove an older slot (that will require some additional work). Having options like those would be really super, but I don't think using package.mask to do it will be so awful. I think what most people want is for portage not to pull in a package that nothing uses. I'm not a dev nor a programmer but I have yet to see any good reason for installing something that is not being used. It's not being tested to see if it is stable. It would have to be used before that would happen. Basically, it is just one more package to update and taking up hard drive space. It's not doing anything else. As for slots, if something needs it, portage would pull in the new slot. That's what portage does. It just seems in this case it is pulling in a new slot that nothing uses. Dale :-) :-)
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Fri, 19 Mar 2010 03:54:28 -0500 Dale rdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Ciaran McCreesh wrote: On Fri, 19 Mar 2010 03:54:28 -0500 Dalerdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org 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. 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? Since python-3 is not what the system is using, it's not getting used even if it is installed. So as I mentioned in another reply, portage is installing something and it is just sitting there doing nothing. What is the point in that? Dale :-) :-)
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Zac Medico wrote: I think what most people want is for portage not to pull in a package that nothing uses. I'm not a dev nor a programmer but I have yet to see any good reason for installing something that is not being used. It's not being tested to see if it is stable. It would have to be used before that would happen. Basically, it is just one more package to update and taking up hard drive space. It's not doing anything else. As for slots, if something needs it, portage would pull in the new slot. That's what portage does. It just seems in this case it is pulling in a new slot that nothing uses. Have you considered that they might possibly be hundreds of packages that you have installed providing functionality that you never use, but are only there as a fixed dependencies of something that you do. Hell lets take it even further than that, i'm sure there are thousands of lines of code in most packages that you will never hit, so why dont we start masking them as well. I don't recall ever using grep --version, please remove (mask) that code from grep. We will obviously need someway to unmask those code masks so lets create a couple of files for portage. Hows code.mask and code.unmask with a format of package path/to/file line1 line2 line3 line4 Or maybe we could just let users who don't want to install python-3 mask it _locally_. Once they need it portage is more than capable of telling them that. Dale :-) :-)
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-19 10:23:31 Dale napisał(a): Ciaran McCreesh wrote: On Fri, 19 Mar 2010 03:54:28 -0500 Dalerdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org 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. 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? Since python-3 is not what the system is using, it's not getting used even if it is installed. So as I mentioned in another reply, portage is installing something and it is just sitting there doing nothing. What is the point in that? I can add python2 USE flag (enabled by default) to some versions of dev-lang/python. With USE=-python2, Python 2 will not be required and Python 3 will be set as main active version of Python. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 19.3.2010 11.35, Arfrever Frehtes Taifersar Arahesis wrote: I can add python2 USE flag (enabled by default) to some versions of dev-lang/python. With USE=-python2, Python 2 will not be required and Python 3 will be set as main active version of Python. You should move to the same scheme that ruby uses. Then users can just disable the python_version_3 or whatever USE_EXPAND scheme is used. Regards, Petteri
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Fri, Mar 19, 2010 at 04:23:31AM -0500, Dale wrote: 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? To some degree it's the users choice which python version they choose to settle on- a simple server system doing file sharing could actually be py3k via portage/pkgcore both supporting py3k (including their dependencies). As for py3k only pkgs, I'd bet 3to2 is py3k only... it's worth noting that some new libs are targeting py3k only also (I don't agree with that, but it's upstreams choice). Since python-3 is not what the system is using, it's not getting used even if it is installed. So as I mentioned in another reply, portage is installing something and it is just sitting there doing nothing. What is the point in that? Mask the freaking package already. The time people have extended in bitching about this *literally* exceeds the time to type mkdir -p /etc/portage \ echo '=dev-lang/python-3' /etc/portage/package.mask If you consider masking it to be that horrible (or want to keep expending time), fine- then please do what Betelgeuse has suggested in IRC and raid from the ruby eclass the USE_EXPAND'd ruby_targets trickery and integrate that into the python eclass [1]. Via that (and a lot of ebuild cleanup) users could explicitly specify the python versions they want targeted and it would properly be represented in the depgraph. ~harring [1] Note that python.eclass already has something *roughly* similar to this, but 1) it's not USE based, 2) no one aparently knows about it, 3) from what I've seen most ebuilds haven't really been converted to handle this properly (yet). pgpfuTlCbt1ph.pgp Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-19 10:39:07 Petteri Räty napisał(a): On 19.3.2010 11.35, Arfrever Frehtes Taifersar Arahesis wrote: I can add python2 USE flag (enabled by default) to some versions of dev-lang/python. With USE=-python2, Python 2 will not be required and Python 3 will be set as main active version of Python. You should move to the same scheme that ruby uses. Then users can just disable the python_version_3 or whatever USE_EXPAND scheme is used. We are waiting on ABI dependencies (and extended support for multiple ABIs in package manager), which will provide some needed functionality. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Fri, Mar 19, 2010 at 10:55:03AM +0100, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-19 10:39:07 Petteri Räty napisał(a): On 19.3.2010 11.35, Arfrever Frehtes Taifersar Arahesis wrote: I can add python2 USE flag (enabled by default) to some versions of dev-lang/python. With USE=-python2, Python 2 will not be required and Python 3 will be set as main active version of Python. You should move to the same scheme that ruby uses. Then users can just disable the python_version_3 or whatever USE_EXPAND scheme is used. We are waiting on ABI dependencies (and extended support for multiple ABIs in package manager), which will provide some needed functionality. You can do it now w/out waiting on ABI dependencies- I'm not saying the dependencies would be pretty, but it's doable to get abi level depdencies per slotting via expanding out the use combinations. Note that's a step beyond what's in place now- converting over to the ruby abuse of USE_EXPAND hands over better control to users now w/ the same dep gurantees. So... yeah, it's not reliant on EAPI. An EAPI extension *would* make it easier, but it's not required to do it (especially since the deps are already autogenerated to a decent degree). ~harring pgpSGu5ROjiqN.pgp Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Fri, 19 Mar 2010 02:56:08 -0700 Brian Harring ferri...@gmail.com wrote: We are waiting on ABI dependencies (and extended support for multiple ABIs in package manager), which will provide some needed functionality. You can do it now w/out waiting on ABI dependencies- I'm not saying the dependencies would be pretty, but it's doable to get abi level depdencies per slotting via expanding out the use combinations. Note that's a step beyond what's in place now- converting over to the ruby abuse of USE_EXPAND hands over better control to users now w/ the same dep gurantees. So... yeah, it's not reliant on EAPI. An EAPI extension *would* make it easier, but it's not required to do it (especially since the deps are already autogenerated to a decent degree). How would do it and deal with existing packages not having the required things in IUSE without (+)/(-) use deps? I don't see a way of doing it legally without those. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On 03/19/2010 01:52 AM, Dale wrote: I think what most people want is for portage not to pull in a package that nothing uses. I'm not a dev nor a programmer but I have yet to see any good reason for installing something that is not being used. It's not being tested to see if it is stable. It would have to be used before that would happen. Basically, it is just one more package to update and taking up hard drive space. It's not doing anything else. It won't be pulled in unless something else is pulled in that can use python3. As for slots, if something needs it, portage would pull in the new slot. That's what portage does. It just seems in this case it is pulling in a new slot that nothing uses. The problem is, most people will have have something pulled in via dependencies that can use python3, even though python-2.x will suffice. For cases like this, some users may want to use package.mask in order to prevent python3 from being installed. -- Thanks, Zac
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Ciaran McCreesh wrote: On Fri, 19 Mar 2010 04:23:31 -0500 Dalerdalek1...@gmail.com 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. Am I not correct in that? If the new python is installed, what exactly is going to use it? I used the new gcc. It worked fine. I unmerged the old one with no wasted space and one less package installed. This doesn't appear to be the case with python-3 tho. It's going to be installed and just sit there like a rock. Dale :-) :-)
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Fri, Mar 19, 2010 at 10:01:05AM +, Ciaran McCreesh wrote: On Fri, 19 Mar 2010 02:56:08 -0700 Brian Harring ferri...@gmail.com wrote: We are waiting on ABI dependencies (and extended support for multiple ABIs in package manager), which will provide some needed functionality. You can do it now w/out waiting on ABI dependencies- I'm not saying the dependencies would be pretty, but it's doable to get abi level depdencies per slotting via expanding out the use combinations. Note that's a step beyond what's in place now- converting over to the ruby abuse of USE_EXPAND hands over better control to users now w/ the same dep gurantees. So... yeah, it's not reliant on EAPI. An EAPI extension *would* make it easier, but it's not required to do it (especially since the deps are already autogenerated to a decent degree). How would do it and deal with existing packages not having the required things in IUSE without (+)/(-) use deps? I don't see a way of doing it legally without those. Roughly, PYTHON_DEPS=pkg1 pkg2 pkg3 SUPPORTED_PYTHONS=2.6 2.7 3.1 inherit insanely-unfriendly-trickery w/in said eclass, it does a few things 1) IUSE addition of the USE_EXPAND targets for the supported abis 2) take the enabled USE_EXPAND'd flags intersected against SUPPORTED_PYTHON, then set deps/rdeps to python_2.6? ( pkg1[python_2.6] pkg2[python_2.6] pkg3[python2.6] ) python_2.7? ( pkg1[python_2.7] pkg2[python_2.7] pkg3[python2.7] ) python_3.1? ( pkg1[python_3.1] pkg2[python_3.1] pkg3[python3.1] ) Yes, that is horrible (ciaran you knew it was going to be). Few flaws with it also- 1) edge case when the user turns off all use flags needs addressing- worst case, python eclass forces whatever we consider the 'default' (aka 2.6) 2) python_2.6 isn't actually a valid use flag- it would have to be python_2-6 or python_26 since periods aren't allowed (arfie pointed this out) 3) this can be ugly for users if the PM doesn't treat use flags as tristate- specifically 'explicitly-set', 'explicitly-unset', 'indeterminant'. If the ocnfiguration forces an explicit and it conflicts w/ the use dep, ok, configuration needs to be changed. If the use flag is indeterminant, then the PM needs to flip the flag on it's own in that case- I know pkgcore should do this, I don't think portage/paludis do (please correct me if wrong). Thing to note, the deps *would* be accurate- further at the vdb level they'd actually be usable. A dev-lang/python in the vdb is basically unusable since implicitly the pkg that has the dep is built against whatever slottings of python were available at the time- so if you take a pkg from now, a year down the line when py3.2 is stabled as far as the PM can tell that pkg *still* would work if =py3.1 were removed (this obviously is not true). Note also that what I laid out above is as far as I know, going a couple of steps beyond what the ruby eclass does (same for what the python eclass does). I'm not necessarily advocating the approach above, but for the raw dev-lang/python dependency we *really* should be using use_expand there- it'll hand folk a fair amount of control as to what abi's get installed into. ~harring pgpxylTOhdfiC.pgp Description: PGP signature
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
2010-03-19 11:13:48 Dale napisał(a): Ciaran McCreesh wrote: On Fri, 19 Mar 2010 04:23:31 -0500 Dalerdalek1...@gmail.com 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. Am I not correct in that? If the new python is installed, what exactly is going to use it? I used the new gcc. It worked fine. I unmerged the old one with no wasted space and one less package installed. This doesn't appear to be the case with python-3 tho. It's going to be installed and just sit there like a rock. Python 3 is used during installation of packages, which support Python 2 and Python 3 and support installation for multiple Python ABIs. You can directly execute scripts with -3.1 suffix (e.g. bpython-3.1 or coverage-3.1) to use Python 3.1 even when Python 2.* is set as main active version of Python. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How about a monthly bumpday?
В Срд, 10/03/2010 в 05:08 +0100, Sebastian Pipping пишет: How about a monthly bumpday? Good idea, but it should follow our policy to inform maintainers _in advance_: e.g. on first bumpday to work on bumps and notify maintainer about this work by attaching final ebuild to the version bump bug with clear message that you are going to bump and, _next month_ on bumpday it's Ok to commit this ebuild to the tree. Just picking bugs and bumping them straight to the tree without knowing why maintainer haven't done that yet is a bad idea. -- Peter.
Re: [gentoo-dev] Add more local USE flags
On 03/19/2010 02:06 AM, Mike Frysinger wrote: On Thursday 18 March 2010 09:17:43 Thomas Kahle wrote: use.local.desc is automatically generated from metadata.xml files, so it's the same thing And this will soon be properly documented: http://bugs.gentoo.org/show_bug.cgi?id=309963 funny, it's in my `man portage` and has been for a while I must admit that I did not look there (I tend to use internet search), but it is also not in my current manpage (=sys-apps/portage-2.1.7.17) use.local.desc All local USE flags must be listed here along with the package and a description. Format: - comments begin with # (no inline comments) - package:use flag - description Not a word of metadata.xml or auto-generation. -- Thomas Kahle The fundamental theorem of algebra is open source. Like any other mathematical theorem it can be applied free of charge and everybody has access to its proof and can convince himself how it works. Why should software be any different? signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: turn on udev use flag by default
Any objections to turning on the udev use flag by default in the base profile? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 03/18/2010 04:34 PM, Ben de Groot wrote: Recruitment being the bottleneck that it is (with candidates waiting many months), it is good to have another option for people who want to contribute. If we do have a list of people waiting to get in, could we maybe publish this list somewhere, or instruct these people to look for maintainer-wanted bugs and offer their services as proxy-maintainers? Can we have some way of communicating that one of these almost-devs has written some ebuilds so that devs can work with them to get them committed? This would get them a head-start and will give them VERY practical instruction. For the devs that work with them they'll know that they're working with somebody with a long-term interest. I'm not sure that we want a policy that states that when the recruits become devs that they will maintain these packages long-term, but it would be nice if they did so. Perhaps the devs could also provide feedback to the recruiters on the recruit's strong/weak points so that they could work on these. (NOTE - I'm not suggesting marking people for exclusion here - if somebody is fairly raw we want to work with them, but it doesn't hurt for the recruiters to know about that up-front.) I realized that some of these ideas are still half-baked, but I'm wondering if there isn't an opportunity here. Rich
Re: [gentoo-dev] RFC: turn on udev use flag by default
On 19-03-2010 15:59:07 +0200, Petteri Räty wrote: Any objections to turning on the udev use flag by default in the base profile? Yeah, can we just do it in the Linux profiles only somewhere? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: turn on udev use flag by default
On 03/19/2010 04:04 PM, Fabian Groffen wrote: On 19-03-2010 15:59:07 +0200, Petteri Räty wrote: Any objections to turning on the udev use flag by default in the base profile? Yeah, can we just do it in the Linux profiles only somewhere? If udev doesn't work on the system, the flag should be masked like it's already on BSD. Is there some place where udev works, but shouldn't be on by default? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: turn on udev use flag by default
On 03/19/2010 04:04 PM, Fabian Groffen wrote: On 19-03-2010 15:59:07 +0200, Petteri Räty wrote: Any objections to turning on the udev use flag by default in the base profile? Yeah, can we just do it in the Linux profiles only somewhere? or rather mask the 'udev' use flag on profiles not supporting it
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-19 11:13:48 Dale napisał(a): Ciaran McCreesh wrote: On Fri, 19 Mar 2010 04:23:31 -0500 Dalerdalek1...@gmail.com 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. Am I not correct in that? If the new python is installed, what exactly is going to use it? I used the new gcc. It worked fine. I unmerged the old one with no wasted space and one less package installed. This doesn't appear to be the case with python-3 tho. It's going to be installed and just sit there like a rock. Python 3 is used during installation of packages, which support Python 2 and Python 3 and support installation for multiple Python ABIs. You can directly execute scripts with -3.1 suffix (e.g. bpython-3.1 or coverage-3.1) to use Python 3.1 even when Python 2.* is set as main active version of Python. But again, if it will work with python2 then you don't need python3. So you still don't need it installed just as has been said many times. Dale :-) :-)
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Alistair Bush wrote: Zac Medico wrote: I think what most people want is for portage not to pull in a package that nothing uses. I'm not a dev nor a programmer but I have yet to see any good reason for installing something that is not being used. It's not being tested to see if it is stable. It would have to be used before that would happen. Basically, it is just one more package to update and taking up hard drive space. It's not doing anything else. As for slots, if something needs it, portage would pull in the new slot. That's what portage does. It just seems in this case it is pulling in a new slot that nothing uses. Have you considered that they might possibly be hundreds of packages that you have installed providing functionality that you never use, but are only there as a fixed dependencies of something that you do. Hell lets take it even further than that, i'm sure there are thousands of lines of code in most packages that you will never hit, so why dont we start masking them as well. I don't recall ever using grep --version, please remove (mask) that code from grep. We will obviously need someway to unmask those code masks so lets create a couple of files for portage. Hows code.mask and code.unmask with a format of package path/to/file line1 line2 line3 line4 Or maybe we could just let users who don't want to install python-3 mask it _locally_. Once they need it portage is more than capable of telling them that. Dale :-) :-) Because in my opinion, portage is the first thing in line to keep a system sane. Installing packages that are not needed means that portage fails on that. So in your example, portage fails to do its due diligence and it falls to the users to do it for portage. Yep, sounds like a good idea. If a package has something that I don't need, I can generally disable that with the USE flags. That is why I picked Gentoo as my distro. I can disable/remove things that I don't need. If Gentoo is going to start putting a lot of unneeded stuff on my system, I may as well go back to Mandriva and off the RPM cliff. I left Mandrake to get rid of unneeded packages. Now Gentoo is doing the same just not nearly as bad. This would be like a small bump in the huge hill that Mandriva has. Dale :-) :-)
[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 Dalerdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org 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
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
On Fri, 19 Mar 2010 10:02:44 -0500 Dale rdalek1...@gmail.com wrote: Because in my opinion, portage is the first thing in line to keep a system sane. Installing packages that are not needed means that portage fails on that. So in your example, portage fails to do its due diligence and it falls to the users to do it for portage. Yep, sounds like a good idea. No, portage does what the dependencies are telling it to do. I.e., if you have unversioned dev-lang/python in DEPEND, or =dev-lang/python-2.4 or whatever similar then it installs dev-lang/python:3 - why? Because the ebuilds tell portage that it will work like that. Another example: you have an ebuild that only works w/ gtk+-1* - you don't go to the ML asking for masking gtk+-2* but instead go and fix the dependencies to properly reflect that. So, now you can go and fix the dependencies treewide, or you can simply mask it *locally* if you don't want it. You'd still need to mask it if you install something that *really* works with both 2.x and 3.1 slots if you don't want python-3. It's like with any other slotted stuff in the tree, but for a reason unknown to me it's a huge issue all of a sudden because wh, t3h noes, it's python. And on that note - noone cares why people has lots of dev-libs/boost slots installed and why's the darned thing slotted on every minor version. So while talking about wrong dependencies, maybe the boost maintainer could explain why do we need it slotted like this: SLOT=$(get_version_component_range 1-2) - simply because I'm tired of depcleaning it all the time as nothing requires multiple slots of this thing here. Cheers, DN signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: turn on udev use flag by default
On Friday 19 March 2010 10:07:59 Petteri Räty wrote: On 03/19/2010 04:04 PM, Fabian Groffen wrote: On 19-03-2010 15:59:07 +0200, Petteri Räty wrote: Any objections to turning on the udev use flag by default in the base profile? Yeah, can we just do it in the Linux profiles only somewhere? If udev doesn't work on the system, the flag should be masked like it's already on BSD. Is there some place where udev works, but shouldn't be on by default? wouldnt it make more sense to invert the logic ? udev only works on linux, so mask it everywhere by default and unmask it for linux profiles. -mike 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 Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziaras rea...@arcor.de wrote: On 03/19/2010 10:57 AM, Ciaran McCreesh wrote: On Fri, 19 Mar 2010 03:54:28 -0500 Dalerdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org 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
Re: [gentoo-dev] RFC: turn on udev use flag by default
On 03/19/2010 07:25 PM, Mike Frysinger wrote: On Friday 19 March 2010 10:07:59 Petteri Räty wrote: On 03/19/2010 04:04 PM, Fabian Groffen wrote: On 19-03-2010 15:59:07 +0200, Petteri Räty wrote: Any objections to turning on the udev use flag by default in the base profile? Yeah, can we just do it in the Linux profiles only somewhere? If udev doesn't work on the system, the flag should be masked like it's already on BSD. Is there some place where udev works, but shouldn't be on by default? wouldnt it make more sense to invert the logic ? udev only works on linux, so mask it everywhere by default and unmask it for linux profiles. -mike What matters is the amount of entries. Do we have more linux than other profiles? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: turn on udev use flag by default
On Friday 19 March 2010 17:06:19 Petteri Räty wrote: On 03/19/2010 07:25 PM, Mike Frysinger wrote: On Friday 19 March 2010 10:07:59 Petteri Räty wrote: On 03/19/2010 04:04 PM, Fabian Groffen wrote: On 19-03-2010 15:59:07 +0200, Petteri Räty wrote: Any objections to turning on the udev use flag by default in the base profile? Yeah, can we just do it in the Linux profiles only somewhere? If udev doesn't work on the system, the flag should be masked like it's already on BSD. Is there some place where udev works, but shouldn't be on by default? wouldnt it make more sense to invert the logic ? udev only works on linux, so mask it everywhere by default and unmask it for linux profiles. What matters is the amount of entries. Do we have more linux than other profiles? no, we dont. stacked profiles means theres 1 linux base. -mike signature.asc Description: This is a digitally signed message part.
[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 Dalerdalek1...@gmail.com 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
