On Tue, Dec 6, 2011 at 2:06 AM, Claudio Freire
On Mon, Dec 5, 2011 at 8:30 PM, todd rme
wrote: I haven't done a detailed check of how many packages have this issue, but amongst the admittedly small number of packages I have looked at all of them have it.
Let me save you some trouble: libs don't have the issue.
As per package naming convention, that means most (if not all) of the packages beginning with "python-".
That is simply not true. A great many "libs" also install files in /usr/bin. Just look in the spec file of devel:languages:python if you don't believe me. From what I have seen, a large fraction of the packages named "python-____" install something in /usr/bin, even if they are just supposed to be libs.
Of those that aren't libs, many don't need support for both python versions. mercurial for example. Any version you pick is OK, since it's just a standalone app. You'd only need both versions if they expose a programmatic API other packages depend on (like with sip and cxfreeze).
The vast majority of packages in devel:languages:python are libs.
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.
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? 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. -Todd -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org