Created attachment 350722 [details, diff] python-single-r1.eclass.patch When ebuild supports single Python version, then corresponding USE flag could be enabled by default to avoid problems. Without patch: $ emerge -Opv blender These are the packages that would be merged, in order: !!! Problem resolving dependencies for media-gfx/blender !!! The ebuild selected to satisfy "blender" has unmet requirements. - media-gfx/blender-2.66::gentoo USE="boost bullet dds elbeem ffmpeg fftw game-engine jpeg2k nls openal openexr openmp sdl sndfile sse tiff -collada -colorio -cycles -debug -doc -jack -ndof -player -redcode" ELIBC="glibc" KERNEL="linux" PYTHON_SINGLE_TARGET="-python3_3" PYTHON_TARGETS="python3_3" USERLAND="GNU" The following REQUIRED_USE flag constraints are unsatisfied: python_single_target_python3_3 The above constraints are a subset of the following complete expression: python_single_target_python3_3? ( python_targets_python3_3 ) exactly-one-of ( python_single_target_python3_3 ) player? ( game-engine ) redcode? ( jpeg2k ) cycles? ( boost ) nls? ( boost ) $ With patch: $ emerge -Opv blender These are the packages that would be merged, in order: [ebuild N ] media-gfx/blender-2.66::gentoo USE="boost bullet dds elbeem ffmpeg fftw game-engine jpeg2k nls openal openexr openmp sdl sndfile sse tiff -collada -colorio -cycles -debug -doc -jack -ndof -player -redcode" PYTHON_SINGLE_TARGET="python3_3" PYTHON_TARGETS="python3_3" 36,050 kB Total: 1 package (1 new), Size of downloads: 36,050 kB $
I don't know. This is a terribly corner-case, and will work seamlessly only for isolated packages. In the particular case of blender, enabling py3.3 implicitly like this will only cause portage to request enabling py3.3 on numpy, then numpy on setuptools and maybe nose... and in the end, user doesn't even know what's happening. That said, explicit 'you need to enable py3.3, sorry' seems better than implicit 'you need to set X flag on A, B, C and D'.
Ok, so in the best case for a user, he already has python3_3 in PYTHON_TARGETS, and the merge proceeds regardless of their PYTHON_SINGLE_TARGET setting. Worst case, he ends up with an error like this: emerge: there are no ebuilds built with USE flags to satisfy "dev-python/numpy[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]". !!! One of the following packages is required to complete your request: - dev-python/numpy-1.7.1::gentoo (Change USE: +python_targets_python3_3) - media-gfx/blender-2.66::gentoo (Change USE: -python_targets_python3_3, this change violates use flag constraints defined by media-gfx/blender-2.66: 'python_single_target_python3_3? ( python_targets_python3_3 ) exactly-one-of ( python_single_target_python3_3 ) player? ( game-engine ) redcode? ( jpeg2k ) cycles? ( boost ) nls? ( boost )') (dependency required by "media-gfx/blender-2.66" [ebuild]) (dependency required by "blender" [argument]) This change would work out better for blender if we had python3_3 in the default PYTHON_TARGETS. Are there any other examples of packages that inherit python-single-r1 but do not support python2.7?
This also affects to devhelp: # USE="gedit" emerge -1av --digest devhelp * * The --digest option can prevent corruption from being noticed. The * `repoman manifest` command is the preferred way to generate manifests * and it is capable of doing an entire repository or category at once. * These are the packages that would be merged, in order: Calculating dependencies / !!! Problem resolving dependencies for dev-util/devhelp ... done! !!! The ebuild selected to satisfy "devhelp" has unmet requirements. - dev-util/devhelp-3.8.2::gentoo USE="gedit" PYTHON_SINGLE_TARGET="-python3_2" PYTHON_TARGETS="python3_2" The following REQUIRED_USE flag constraints are unsatisfied: gedit? ( python_single_target_python3_2 ) The above constraints are a subset of the following complete expression: gedit? ( python_single_target_python3_2? ( python_targets_python3_2 ) exactly-one-of ( python_single_target_python3_2 ) )
Other option would be to set it as enabled by default at ebuild level instead of eclass
(In reply to Pacho Ramos from comment #3) > This also affects to devhelp: > # USE="gedit" emerge -1av --digest devhelp > * > * The --digest option can prevent corruption from being noticed. The > * `repoman manifest` command is the preferred way to generate manifests > * and it is capable of doing an entire repository or category at once. > * > > These are the packages that would be merged, in order: > > Calculating dependencies / > > !!! Problem resolving dependencies for dev-util/devhelp > ... done! > > !!! The ebuild selected to satisfy "devhelp" has unmet requirements. > - dev-util/devhelp-3.8.2::gentoo USE="gedit" > PYTHON_SINGLE_TARGET="-python3_2" PYTHON_TARGETS="python3_2" Isn't it going to support 3.3 anytime soon? If it does, then this whole idea becomes moot. Ebuild-level sounds indeed a bit better. What happens if ebuild has 3.2+3.3, you +-default 3.2, and user has 3.3 in his P_S_T?
I don't think we should point people to play with PYTHON_SINGLE_TARGET by themselves in their make.conf. I think the way to go would be to try to get PYTHON_SINGLE_TARGET "defaults" based in PYTHON_TARGETS. For example, currently we have this: # Mike Gilbert <floppym@gentoo.org> (15 May 2012) # Default target(s) for python-r1.eclass PYTHON_TARGETS="python2_7 python3_2" PYTHON_SINGLE_TARGET="python2_7" The idea would be to fallback to the other PYTHON_TARGETS value when "python2.7" cannot satisfy PYTHON_SINGLE_TARGET
Also rhythmbox is affected by this, I have seen the following: PYTHON_SINGLE_TARGET="python3_2 python2_7" works. Then, I thing would be feasible to set PYTHON_TARGETS and PYTHON_SINGLE_TARGET to the same value in profiles What do you think?
(In reply to Pacho Ramos from comment #7) > Also rhythmbox is affected by this, I have seen the following: > PYTHON_SINGLE_TARGET="python3_2 python2_7" > > works. Then, I thing would be feasible to set PYTHON_TARGETS and > PYTHON_SINGLE_TARGET to the same value in profiles > > What do you think? Unless I'm missing something, this will be a terrible failure for every package that supports 2.7 and 3.2 at the same time.
(In reply to Michał Górny from comment #8) > Unless I'm missing something, this will be a terrible failure for every > package that supports 2.7 and 3.2 at the same time. Umm, but shouldn't that packages supporting 2.7 and 3.2 use python-r1 instead of python-single-r1?
(In reply to Pacho Ramos from comment #9) > (In reply to Michał Górny from comment #8) > > Unless I'm missing something, this will be a terrible failure for every > > package that supports 2.7 and 3.2 at the same time. > > Umm, but shouldn't that packages supporting 2.7 and 3.2 use python-r1 > instead of python-single-r1? And, the other option that comes to my mind is relying on affected ebuilds enabling the implementation in ebuild itself. But I still think would be better to do at eclass level as, doing it in the eclass could let us choose a default taking preferences as python team decides (like python2.7 as first option, python3.2 (or the option stabilized at the moment) as second if 2.7 isn't available). The problem is that current situation will simply show a ugly error at people when simply doing "emerge rhythmbox". I thought this was only affecting to corner cases, but looks like we will see more cases of packages using single-r1 eclass with python3 implementations in the future :/
(In reply to Pacho Ramos from comment #10) [...] > And, the other option that comes to my mind is relying on affected ebuilds > enabling the implementation in ebuild itself. OK, per comment #1 this has also problems. But reading comment #8, setting PYTHON_SINGLE_TARGETS=${PYTHON_TARGETS} will also cause problems... then, what should people do in their make.conf? - If they enable both they will fail in packages having both - If they set it to python2.7, packages only supporting other implementation will fail - If they set it to python3.2 the same I think PYTHON_SINGLE_TARGETS=${PYTHON_TARGETS} should be allowed and used as default and, then, python-single-r1.eclass should use its first value only, that way: - If a package supports both, the first one will be used - If a package supports only 2.7, that one will be used, the same for 3.2 - If a package support 3.2 and 3.5 (for example), the first (3.2) will be used
(In reply to Pacho Ramos from comment #11) > I think PYTHON_SINGLE_TARGETS=${PYTHON_TARGETS} should be allowed and used > as default and, then, python-single-r1.eclass should use its first value > only I doubt this will allow us to have proper inter-package dependencies since a single flag may or may not be meaningful, depending on the state of other flags. The only solution so far is to use package.use per-package.
(In reply to Michał Górny from comment #12) > (In reply to Pacho Ramos from comment #11) > > I think PYTHON_SINGLE_TARGETS=${PYTHON_TARGETS} should be allowed and used > > as default and, then, python-single-r1.eclass should use its first value > > only > > I doubt this will allow us to have proper inter-package dependencies since a > single flag may or may not be meaningful, depending on the state of other > flags. > But, won't PM take care of it as the flag would be changed globally for all packages? :/ > The only solution so far is to use package.use per-package. Looks feasible too (but not sure if we are thinking in the same :P) Thanks for your help on this :)
(In reply to Pacho Ramos from comment #13) > > I doubt this will allow us to have proper inter-package dependencies since a > > single flag may or may not be meaningful, depending on the state of other > > flags. > > > > But, won't PM take care of it as the flag would be changed globally for all > packages? :/ No. Let's assume A deps on B. A supports 2.7, and B supports 2.7+3.2. All you can do is ensure that *if A has 2.7, B has 2.7 as well*. That works with current design. If we allow enabling both 2.7 & 3.2 on B, the latter case will cause 2.7 dep to be satisfied while 3.2 will be actually available.
(In reply to Michał Górny from comment #14) [...] > No. > > Let's assume A deps on B. A supports 2.7, and B supports 2.7+3.2. All you > can do is ensure that *if A has 2.7, B has 2.7 as well*. That works with > current design. If we allow enabling both 2.7 & 3.2 on B, the latter case > will cause 2.7 dep to be satisfied while 3.2 will be actually available. But, cannot python dependencies be forced to be in sync? I mean, if A only supports python2.7 it needs to force deps to be 2.7 too, no? Since PYTHON_SINGLE_TARGETS would contain both (2.7 and 3.2), PM would choose 2.7 for both :/ Anyway, as you know much more about PM internals, how the package.use would be used? I guess we should be able to enable it by default in some way, but not sure if at profile level or ebuild level (with +USE)
(In reply to Pacho Ramos from comment #15) > (In reply to Michał Górny from comment #14) > [...] > > No. > > > > Let's assume A deps on B. A supports 2.7, and B supports 2.7+3.2. All you > > can do is ensure that *if A has 2.7, B has 2.7 as well*. That works with > > current design. If we allow enabling both 2.7 & 3.2 on B, the latter case > > will cause 2.7 dep to be satisfied while 3.2 will be actually available. > > But, cannot python dependencies be forced to be in sync? I mean, if A only > supports python2.7 it needs to force deps to be 2.7 too, no? Since > PYTHON_SINGLE_TARGETS would contain both (2.7 and 3.2), PM would choose 2.7 > for both :/ They can't. Since A doesn't support 3.2, you can't do anything special with it. The best thing we could do is having '-python_single_target_python3_2' in PYTHON_USEDEP but then it would cause issues the other way around. > Anyway, as you know much more about PM internals, how the package.use would > be used? I guess we should be able to enable it by default in some way, but > not sure if at profile level or ebuild level (with +USE) I meant *users* will be supposed to enable the impls in package.use. Playing with defaults like this is simply short-sighted.
But thinking in rhythmbox case (for example), looks wrong to me to provide people something that they won't be able to merge if they don't enable python3.2 for it. Wouldn't be better to we enabling it *for that package* as it's the only option to get it working with python?
I don't think there's a real point in doing that. While it would help right now, it will have to be removed once again as soon as rhythmbox starts to support another impl. So it'll be a swing for users.
Well, the idea would be: 1. Now that only supports 3.2 -> set is as default 2. Once it supports 3.2 and 3.3, since 2.7 will be kept as default PYTHON_SINGLE_TARGETS, we would the default taking care about what is is default python3 implementation (usually the newer stable one) The main problem is that, currently, the kind of message that people will get won't be useful at all to a lot of people and, also, it increases the risk of people wrongly enabling multiple PYTHON_SINGLE_TARGET in their make.conf :(
Looking at the pending updates, I guess we're now at the move from 3.3 to 3.4. The gnome-music ebuild is the only one giving me "manual trouble". on the other hand, it seems to refer to this bug to justify its use of IUSE defaults.
*** Bug 575814 has been marked as a duplicate of this bug. ***
*** Bug 575820 has been marked as a duplicate of this bug. ***
*** Bug 516588 has been marked as a duplicate of this bug. ***
*** Bug 592356 has been marked as a duplicate of this bug. ***
This has been fixed long time ago, albeit a bit different (without PYTHON_SINGLE_TARGET at all).
