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