[18:25] <mgorny> if you could open a bug on bitbucket or gentoo bugzie, i'd appreciate relevant part of the ebuild: src_install(){ distutils-r1_src_install dosym /usr/bin/${PN}{.py,} } ls -l retex* lrwxrwxrwx 1 root root 18 2. Dez 18:13 retext -> /usr/bin/retext.py* lrwxrwxrwx 1 root root 11 2. Dez 18:13 retext.py -> python-exec* -rwxr-xr-x 1 root root 1955 2. Dez 18:13 retext.py-python2.7* -rwxr-xr-x 1 root root 1955 2. Dez 18:13 retext.py-python3.2* start retext: % retext retext: no supported Python implementation variant found!
I see two solutions here: a canonical one and an easy one. The canonical one is to use readlink(). Either: a) readlink() up to python-exec itself, then go back one step, b) readlink() after trying all the names, then retry. But honestly, I dislike it. It makes the code more complex and slower. And it still doesn't handle the case if someone tried to use hardlink instead of symlink, or just copied the file because symlinks aren't supported. The other, easy solution is to simply duplicate the symlinks. Main advantage of that is that it works without touching python-exec's code at all, and it's no less efficient that the current code. That leaves the question to the choice of an API. I think distutils-r1 should simply modify rename_files() to handle the case when distutils directly installs symlinks like that. For manual installs like this one, I'd put python_dosym() which would symlink the wrapped executable and the wrapper.
I have added initial symlink resolution support to python-exec-9999. I'd appreciate testing before I unleash it.
Note to self: have to fix Python counter-part too.
Ah, yes, it's fixed in 0.3.
