Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#29004 - [python] 2/3 conflicts in /usr/bin

Attached to Project: Arch Linux
Opened by Simon Sapin (SimonSapin) - Monday, 19 March 2012, 12:33 GMT
Last edited by Allan McRae (Allan) - Friday, 16 November 2012, 12:34 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Stéphane Gaudreault (stephane)
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

More and more Python projects support both Python 2 and 3, which is great. The packaging convention is to have a python-something package for Python 3 and python2-something for Python 2. That is fine.

The problem is for projects that have command-line executables. If special care is not taken, both packages will install the same file in /usr/bin, causing a conflict. I’ve seen two pattern in existing packages to resolve this:

1. Have only one of the packages install the scripts. For example, the PKGBUILD for python-pygments has this line, so that pygmentize is only installed by python2-pygments: rm "$pkgdir/usr/bin/pygmentize"

2. Rename the scripts in one of the packages. For example in python2-pip: mv "$pkgdir/usr/bin/pip" "$pkgdir/usr/bin/pip2". python2-tox has something similar.

Solution 1 is bad because if I install just one of the packages, I may end up with no script at all, ie. missing functionnality.
Solution 2 is fine for some projects: when using pip, I really want to know what Python version is used. For other projects however I don’t care. tox for example creates its own virtualenvs, /usr/bin/tox2 really is the same as /usr/bin/tox. Why should I have to change my scripts if I installed the "wrong" one?

Finally, the wiki does not mention any of this, I had to research existing packages in ABS myself when I wanted to package WeasyPrint for the AUR.
https://wiki.archlinux.org/index.php/Python_Package_Guidelines


A first step would be to adopt Solution 1 or 2 or something else and document it in the wiki as "best practice". However neither is really satisfactory.



The situation is better with emerge in Gentoo: packages have a metadata saying which Python versions they support; users choose in configuration which versions they want to install and which one is their "favorite". Emerge then handle Python stuff in /usr/bin itself: it creates files with suffixes like -2.7, and a symlink without the suffix for the favorite version.

Proposition for pacman: while keeping separate python- and python2- packages as done now, PKGBUILD could have additional metadata to instruct pacman how to handle the scripts itself. For example, the python-tox packages would have metadata that say "I am creating /usr/bin/tox for Python 3.2" and python2-tox would say "I am creating /usr/bin/tox for Python 2.7". Pacman would then rename each script to tox-3.2 and tox-2.7 (or tox-3 and tox-2) and make a /usr/bin/tox symlink as soon as either version is installed, choosing the "favorite" version if both are installed.

At first the "favorite" could be always Python 3 (like /usr/bin/python itself). If there is demand, consider having a configuration entry for this in /etc/pacman.conf


So the current situation is not very satisfactory and I think it could be improved, one way or another. Thought?
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 16 November 2012, 12:34 GMT
Reason for closing:  Not a bug
Additional comments about closing:  File bugs for packages with issues
Comment by Massimiliano Torromeo (mtorromeo) - Monday, 19 March 2012, 17:05 GMT
There is one possible solution that would not require any special handling by pacman.

Example solution for the pygments packages:
Both packages could install their respective script as /usr/bin/pygmentize2 and /usr/bin/pygmentize3, then 2 additional small packages python2-pygmentize-link and python-pygmentize-link (the name could be something else of course) would only provide a symlink to the corresponding chosen binary.

python2-pygmentize-link would contain the symlink "/usr/bin/pygmentize > /usr/bin/pygmentize2"
python-pygmentize-link would have "/usr/bin/pygmentize > /usr/bin/pygmentize3"

and obviously the 2 packages would conflict with each other and python2-pygmentize-link should also provide python-pygmentize-link so that other packages could just have a dependency to python-pygmentize-link if they don't require a particular implementation.

Having two additional packages to install just a symlink may be a little overkill but it would solve the problem just fine.

My only concern about this is that it would probably clutter AUR too much because of the missing support for split packages.
Comment by Ike Devolder (BlackEagle) - Monday, 19 March 2012, 17:41 GMT

Loading...