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
