On Tue, Dec 6, 2011 at 6:03 AM, todd rme
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)
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. 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.
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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org