The new method of storing the original scripts using: /usr/lib/python-exec/${EPYTHON}/$(basename ${SCRIPT}) Assumes that every single script at system has unique name, which is somewhat far fetched. What is the solution for two separate scripts, for example config.py located at two different directories, example: /usr/share/xxx/config.py /usr/share/yyy/config.py When scripts were at the location of the wrapper there was no such problem. Thanks,
Is this a real issue or just a theoretical one? The wrapper is intended to wrap scripts that are run by user. Putting Python scripts in /usr/share is incorrect itself, and most likely won't give you the result you want anyway.
(In reply to Michał Górny from comment #1) > Is this a real issue or just a theoretical one? The wrapper is intended to > wrap scripts that are run by user. Putting Python scripts in /usr/share is > incorrect itself, and most likely won't give you the result you want anyway. Why putting python script at /usr/share is incorrect? not all script should be in path, some needed during product one time configuration, cgis, hooks and so on. Assuming that basename of script is unique is incorrect. I thought that this python-exec should be generic mechanism, it was so far.
The obvious solution here (to me) would be to create a mirrored directory structure under /usr/lib/python-exec/${EPYTHON}. Possible problems: 1. Path length limits (unlikely). 2. Symlinked directories; do we use a normalized path? This could get messy. We could keep the current python-exec:2 behavior as a fallback.
(In reply to Alon Bar-Lev from comment #2) > (In reply to Michał Górny from comment #1) > > Is this a real issue or just a theoretical one? The wrapper is intended to > > wrap scripts that are run by user. Putting Python scripts in /usr/share is > > incorrect itself, and most likely won't give you the result you want anyway. > > Why putting python script at /usr/share is incorrect? not all script should > be in path, some needed during product one time configuration, cgis, hooks > and so on. /usr/share is for *data*. Script is not really data. It belongs in /usr/lib. > Assuming that basename of script is unique is incorrect. > > I thought that this python-exec should be generic mechanism, it was so far. Find a good solution. Write a patch. We can all complain if you like but this won't do the necessary work. I'm not going to waste my time over it unless it becomes necessary for some reason.
The solution was there all the time... Use plain suffix for the original scripts leave them at original directories. Not sure why you hurry up to close bugs. You did not provide any solution but stated that all script within the entire world need to be unique, this is invalid assumption.
(In reply to Alon Bar-Lev from comment #5) > The solution was there all the time... > > Use plain suffix for the original scripts leave them at original directories. > As stated in bug 492606, this breaks anything that relies on basename(sys.argv[0]) having a specific value. It's trading one type of breakage for another.
(In reply to Mike Gilbert from comment #6) > (In reply to Alon Bar-Lev from comment #5) > > The solution was there all the time... > > > > Use plain suffix for the original scripts leave them at original directories. > > > > As stated in bug 492606, this breaks anything that relies on > basename(sys.argv[0]) having a specific value. It's trading one type of > breakage for another. Please also don't forget that relying on basename(sys.argv[0]) is much more common and breaks important Gentoo packages. The few I can think of quickly are package managers and gentoolkit.
