On Mon, Dec 5, 2011 at 12:46 PM, todd rme
Yes, that is the whole point of this discussion, to figure out what "something like that" we should actually do. I gave four possible solutions to this issue at the beginning of the discussion. I am bringing this issue up specifically to emphasize why it is important that we come to a decision on which of those options we should actually implement.
Oh, ok... your mention of the validation was misleading, it looked as if you were complaining against the validation ;-)
Here are my suggested solutions again:
1. Add python version information to the beginning of the file name. For example, /usr/bin/sip becomes /usr/bin/python3-sip or /usr/bin/python3.2-sip. This has the benefit that it doesn't require any significant changes to current packaging. It has the disadvantage that anything looking for /usr/bin/sip will not find this file. Another disadvantage is that, as far as I have been able to find, python does not have a built-in way to do this, which would mean that the files have to be manually renamed.
First, if you symlink sip -> preferred version, this would be fully backwards-compatible. Second, true. But most setuptools-based packages support --install-scripts, which at least would put them in a separate folder (you can symlink to them, manually, true).
This is ugly and could potentially break things that are looking for specific file names, as well as making tab-completion on the command line less predictable.
Like I said, symlinks are your friend.
There is also a question of what would happen when python 2 support is ended, and a question of whether this would happen with python 3 packages or both python 2 and python 3 packages.
With symlinks, you simply switch preferred version.
2. Add python version information at the end of the file name. So /usr/bin/sip becomes /usr/bin/sip-3 or /usr/bin/sip-3.2. This has similar issues to 1, but makes tab completion easier at the cost of making it unclear whether 3.2 is the version of sip or the version of python.
Ya, I prefer this one. Just MHO.
4. Create a new directory in %{python3_sitearch). So for example /usr/bin/sip becomes /usr/lib[64]/python3.2/bin/sip. This requires much more radical changes to how python files are handled, and it would be possible to have python2 files do the same.
I don't follow. Are we talking about apps or libs? Libs don't have an issue, they should reside wherever their python version expects them. Apps are the issue. SIP is both, IIRC. So part of SIP (the libs) should go with all the other python2/3 libs, and only the scripts (or symlinks) have special treatment. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org