On Mon, Dec 5, 2011 at 4:39 PM, Claudio Freire
On Mon, Dec 5, 2011 at 12:29 PM, todd rme
wrote: I think you are thinking of a different issue. What I am talking about is not the rpmlint fdupes warning. Rather, it is an error that occurs when two sub-packages of the same package both own a file with the same name but do not conflict with each other.
To provide a relevant example, both the python2 and python3 versions of python-cx_freeze create the file /usr/bin/cxfreeze. If you try to create a package that builds python2 and python3 subpackages for python-cx_freeze, the build will fail because they both contain a file with that name. The only wat to avoid the error is to make the subpackages conflict (which I have done temporarily), but this defeats the purpose of having python2 and python3 both available.
But this would indeed be a packaging error.
You cannot install two packages that own the same file, only one version can exist.
Instead, the python3 version should install cxfreeze3. Or install it to another path. Or something like that.
Certainly, two nonconflicting packages cannot install the a file on the same path. That's an error however you look at it, because one version will be stepped onto by the other.
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. 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. 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. 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.
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.
3. Create a new subdirectory in /usr/bin for python3 files. So for example /usr/bin/sip becomes /usr/bin/python3/sip or /usr/bin/python3.2/sip. This would require changing the path to include this directory. It has the advantage that the files in /usr/bin, which should be earlier in the path, should have priority. It also has the advantage that python has a built-in way to set what directory is used. It also means the file names will remain the same, so nothing will break. Python could also be patched to default to this directory so the install scriptlets would not need to be changed (although the files list scriptlets still would).
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. This has the advantage, however, of being more future-proof (i.e. python 4) and would allow multiple versions of the same python abi to be included (i.e. 3.2 and 3.3). Path priority issues could be solved by making sure /usr/lib[64]/python/bin is first in the path. This currently symlinks to /usr/lib[64]/python2, but simply by changing that /usr/lib[64]/python3 the python3 versions of the files would automatically become the defaults. It would also be easy for users to change by putting one ahead in their per-user path.
As I explained, I consider option 4 to be the best option, especially if we only do it for python3 and leave python2 alone. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org