On Mon, Dec 5, 2011 at 5:04 PM, Claudio Freire
On Mon, Dec 5, 2011 at 12:46 PM, todd rme
wrote: 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 ;-)
Sorry about that.
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).
But if you were doing this you would still need to make the other folder be in the global path, so there wouldn't be any point having it in /usr/bin.
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.
That won't help if the python3 version of a package looks in /usr/bin/ and finds the python2 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.
If we are creating new directories anyway, I think this adds a lot of additional complexity with no real benefit. I think we would only want to do this if we were not going to create new directories.
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.
I am talking about things currently installed in /usr/bin and /usr/share, so what python calls scripts and data, respectively. libs are not a problem because they are already in a versioned directory. The idea of suggestion 4 is to also put the scripts and data in a versioned directory So for example, libs currently go in /usr/lib[64]/python3.2/site-packages/. I would create additional directories: /usr/lib[64]/python3.2/scripts/ -- this would contain the python3 files currently in /usr/bin (the scripts), and would be in the global path (at the end of the path, of course, so python2 scripts currently in /usr/bin would remain the default for now). /usr/lib[64]/python3.2/data/ -- this would contain the python3 files currently in /usr/share (the data), and would NOT be in any path (these directories, of course, would use %{py3_ver} rather than a hard-coded version number). This could be set to happen automatically be changing the default for the --install-scripts and --install-data arguments for python. That would mean the %build and %install scriptlets would not need to be changed at all, only the %files scriplets would need to be changed (and with proper macros for these directories in macros.python3 the change should be very easy and only needs to be done once). This could also be done with python2, but that doesn't need to happen at this point (it would need to happen when python3 becomes the default, though, but that is the case with any of these suggestions). -Todd -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org