1i5t5.duncan at cox
Oct 18, 2009, 6:06 AM
Post #6 of 7
Drake Donahue posted on Sat, 17 Oct 2009 23:08:13 -0400 as excerpted:
> will running python-updater help this?
It may. But the problem is that if the packages it rebuilds are still
using the single python slot method, they'll be rebuilt for whatever's
currently eselect-python-ed. Python3 is still ~arch, and it's likely
that not all packages building python modules have a stable version that
builds for multiple slots yet. Thus, if someone's running a normally
stable system but has the unstable python3 installed, just as with any
mixing of stable and unstable, it's not fully tested or assumed to work,
and they may well have problems unless they update every single python
module containing package to the latest ~arch version, as well as
eselect, so they can get the versions that will install for all slots,
not just whatever happens to be the system python at the time.
Otherwise, what python-updater is likely to do is to update everything to
whatever's eelect-python-ed, but in the process, remove the modules as
they were installed for the other slots, and that's likely not what
people want, particularly since a lot of stuff doesn't even work with
python3 at all yet, so it's almost certain they'll want the modules
installed for at least one python 2.x version, 2.5 or 2.6.
So what I'm saying is that if you /are/ running python3 on a normally
stable system, you better keyword ~arch eselect and all the python module
containing packages, or you /are/ likely to have /something/ broken. And
at this point, only that non-critical binpkg module was complaining, so
it may well be best to leave well enough alone.
The other alternative of course, would be to mask python3 for the time
being, if you don't have anything that specifically uses it. Since it's
~arch-only at present anyway, stable users who have it installed
presumably NEED it for something, but if they don't, and for all ~arch
users (like me) who would have it installed only because it's ~arch, not
because they specifically need it, it may well be best to put >=dev-lang/
python-3.0.0 in your package.mask file, and not worry about it until
something you have installed wants it as a dependency to upgrade.
That's actually what I'm doing at the moment. I have nothing that needs
python-3, so I package.masked it, and don't have it on my system. When
something that I run eventually needs it for an upgrade, I'll worry about
it then, but meanwhile, I'm saving myself quite a bit of grief as various
packages convert over and have various python-3 bugs, that will be fixed
by the time I actually need it installed for something or other. I do my
share of testing, but python-3 is not an area I'm interested in worrying
about, so I don't.
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