| 1 |
Drake Donahue posted on Sat, 17 Oct 2009 23:08:13 -0400 as excerpted: |
| 2 |
|
| 3 |
> will running python-updater help this? |
| 4 |
|
| 5 |
It may. But the problem is that if the packages it rebuilds are still |
| 6 |
using the single python slot method, they'll be rebuilt for whatever's |
| 7 |
currently eselect-python-ed. Python3 is still ~arch, and it's likely |
| 8 |
that not all packages building python modules have a stable version that |
| 9 |
builds for multiple slots yet. Thus, if someone's running a normally |
| 10 |
stable system but has the unstable python3 installed, just as with any |
| 11 |
mixing of stable and unstable, it's not fully tested or assumed to work, |
| 12 |
and they may well have problems unless they update every single python |
| 13 |
module containing package to the latest ~arch version, as well as |
| 14 |
eselect, so they can get the versions that will install for all slots, |
| 15 |
not just whatever happens to be the system python at the time. |
| 16 |
|
| 17 |
Otherwise, what python-updater is likely to do is to update everything to |
| 18 |
whatever's eelect-python-ed, but in the process, remove the modules as |
| 19 |
they were installed for the other slots, and that's likely not what |
| 20 |
people want, particularly since a lot of stuff doesn't even work with |
| 21 |
python3 at all yet, so it's almost certain they'll want the modules |
| 22 |
installed for at least one python 2.x version, 2.5 or 2.6. |
| 23 |
|
| 24 |
So what I'm saying is that if you /are/ running python3 on a normally |
| 25 |
stable system, you better keyword ~arch eselect and all the python module |
| 26 |
containing packages, or you /are/ likely to have /something/ broken. And |
| 27 |
at this point, only that non-critical binpkg module was complaining, so |
| 28 |
it may well be best to leave well enough alone. |
| 29 |
|
| 30 |
The other alternative of course, would be to mask python3 for the time |
| 31 |
being, if you don't have anything that specifically uses it. Since it's |
| 32 |
~arch-only at present anyway, stable users who have it installed |
| 33 |
presumably NEED it for something, but if they don't, and for all ~arch |
| 34 |
users (like me) who would have it installed only because it's ~arch, not |
| 35 |
because they specifically need it, it may well be best to put >=dev-lang/ |
| 36 |
python-3.0.0 in your package.mask file, and not worry about it until |
| 37 |
something you have installed wants it as a dependency to upgrade. |
| 38 |
|
| 39 |
That's actually what I'm doing at the moment. I have nothing that needs |
| 40 |
python-3, so I package.masked it, and don't have it on my system. When |
| 41 |
something that I run eventually needs it for an upgrade, I'll worry about |
| 42 |
it then, but meanwhile, I'm saving myself quite a bit of grief as various |
| 43 |
packages convert over and have various python-3 bugs, that will be fixed |
| 44 |
by the time I actually need it installed for something or other. I do my |
| 45 |
share of testing, but python-3 is not an area I'm interested in worrying |
| 46 |
about, so I don't. |
| 47 |
|
| 48 |
-- |
| 49 |
Duncan - List replies preferred. No HTML msgs. |
| 50 |
"Every nonfree program has a lord, a master -- |
| 51 |
and if you use the program, he is your master." Richard Stallman |
Archives