On Tue, Dec 6, 2011 at 3:25 PM, Claudio Freire
On Tue, Dec 6, 2011 at 6:03 AM, todd rme
wrote: On Tue, Dec 6, 2011 at 2:06 AM, Claudio Freire
wrote: That is simply not true. A great many "libs" also install files in /usr/bin. They shouldn't...
I believe the number of packages won't be that huge.
Let me give some more concrete numbers. I opened the first 20 rows of python-___ packages in devel:languages:python. That is about 170 packages, and I exclude the about 45 packages that use files lists so I can't tell the contents. That leaves about 125 packages. Of those, about 50 have this issue, or about 40%. If that is representative, that is over 370 packages just amongst the python-___ packages in devel:languages:python alone.
That *is* a problem. Python libs shouldn't be installing new binaries... what are they installing? Maybe it's an error. Maybe I just misjudged the number of libs performing dual functions (lib + app)
They aren't usually binaries, they are usually scripts. They appear to mostly be commandline (i.e. bash shell) wrappers around one or more python functions, letting you access one or more of the library's basic capabilities from within bash or other similar shell instead of needing to open a python shell. For instance numpy provides a fortran-to-python converter called f2py, cxfreeze has a script to convert a script to a stand-alone executable, pygment (a source code highlighting function) provides a script to highlight source code and store the highlights to a file, python-googletranslate of course provides a translator script, and so on. For things like pygment and googletranslate it doesn't really matter what is used, but for things like f2py and cxfreeze the version of python the script calls can have a major or even critical impact.
Notice that you could easily build a macro for that rename, since it means renaming all the binaries installed in %{_bindir}. So the change isn't that "personalized" for each package. And if you decide to use a subdirectory within bindir that's even easier, since a macro can create the symlinks with one bash command.
So it *can* be made to scale. It only requires a bit of thought and prevision.
Even with that, it is still not as straightforward as the approach I propose, since it still requires additional lines in the spec file beyond what would be required just to add python3 support to the package. Besides scalability, I listed what I consider to be a number of other advantages to the approach I support.
As for adding them to a subdirectory of bindir, that was another approach I suggested, but once again I only see disadvantages to this approach.
What reasons do you have for choosing the approach you chose?
Only that I do not like the idea of fiddling with standard python paths. It will require a lot of care and testing to make things like setuptools, easy install and in general manually-installed packages to not break.
The problem is we either have to fiddle with paths, or fiddle with names. At least with paths, distutils (and presumably python) is aware of the change. And as you said, it can still be symlinked to the proper place.
Furthermore, when you suffix the binary with the python version, it is rather straightforward to choose a python version:
$ easy_install2 $ easy_install3
Or, the more standard
$ easy_install-2.6 $ easy_install-3.1
From the POV of a user, it is a lot better (a lot more explicit and clean) than fiddling with the PATH.
That is true, although on the other hand it leads to ambiguity about whether the number is the python version or the version of the script.
Of course if there is a reason why this approach would be preferable I would support it. I am trying to figure out the best approach, by looking at the advantages and disadvantages to each approach. I don't see any advantages to this approach, but I very well may just not have thought of them.
With your numbers about the number of lib packages "misbehaving", your option 4 is starting to sound better. I still maintain that it's a lot clearer and cleaner for a user to type "easy_install3" than to fiddle with the PATH in order to get easy_install for python3..
So we're down to what's better for a user vs. what's better for the packager.
It also depends on how likely users are to use the scripts, and how likely they are to care which one they use. -Todd -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org