This annoying bug http://bugs.gentoo.org/show_bug.cgi?id=20248 can be solved by adding >=dev-lang/python-2.4.3-r4 to DEPEND on the pyopengl builds. Why allowing pyopengl to build with python versions that don't work as expected? Cheers
Correction: http://bugs.gentoo.org/show_bug.cgi?id=147809
(In reply to comment #0) > This annoying bug http://bugs.gentoo.org/show_bug.cgi?id=20248 can be solved by > adding >=dev-lang/python-2.4.3-r4 to DEPEND on the pyopengl builds. > > Why allowing pyopengl to build with python versions that don't work as > expected? But the thing is 2.4.3-r1 does work... just not if you installed it before it's USE flags were changed (and refuse to reinstall it)... http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/python-2.4.3-r1.ebuild?r1=1.8&r2=1.9
>2.4.3-r1 does work... just not if you installed it before it's > USE flags were changed (and refuse to reinstall it)... That's the case for all new users using the current stage3, and for people like me using the stage3 for catalyst. As you can see in that bug, people still run into it, and in the forums they show up constantly :P
>(and refuse to reinstall it)... Oh, that's because many don't know they need to, and in case of Catalyst I had to change the ebuild, cause portage emerged hundreds of packages and didn't know python had to be before pyopengl. (and you can only emerge once here)
I guess the new release solves this. The problem is actually the way portage handles new flags. I was thinking that portage could have also 'flag version' : on the requirements it could request a certain flag version of other packages. For instance pyopengl required any python version as long as the ebuild used had flag version 2.
