On Thu, Dec 04, 2014 at 08:10:39AM -0500, Bohuslav Kabrda wrote:
- sphinx-build-v0.9
- sphinx-build-2-v0.9
- sphinx-build-2.7-v0.9
- sphinx-build-3-v0.9
- sphinx-build-3.7-v0.9
I'd rather see sphinx-build-v0.9-3.4. IMO keeping the Python version at the very end in every case is better. In other words, the binary would normally be "sphinx-build-0.9" and we just append "-3.4" to it.
I'm not really attached to whether the v0.9 goes before or after the -3.4 however, the argument was made earlier that upstream naming and documentation, and tab completion were important factors. To remain consistent with that it seems more appropriate to put any Fedora-added suffixes for backwards/forwards compat packages at the very end.
Also, this makes me realize more arguments to append Python version with dash, not without it:
- sphinx-build-v0.93.4 would be very confusing (I do understand that this is a downstream problem, but see the following point)
- Similarly, if there is an upstream whose entry_point/script ends with a number (pep8 for example), it'd be highly confusing to use the notation without dash, it would yield pep83.4 assuming the upstream community would accept this scheme. This feels just wrong.
I'm wholehearterdly in favor of dashes when we're creating these script names too.
I also note that this line of reasoning also lends itself to putting any backwards compat versions at the very end. sphinx-build-v3.1-2 is more ambiguous (especially to a sysadmin who is used to reading rpm NEVR's) than sphinx-build-2-v3.1. The "v" provides additional guidance to someone looking at it that the number following it serves a separate purpose from the number before it.
Anyhow, not really attached so I've stated the reasons I think the fedora-local version suffix makes more sense at the very end and now I'll shut about it ;-)
Also an addition: It would be great for us to always have a "major version number only" script name. Currently there's a few packages (python3-nose, I'm looking at you) that only provide the MAJOR.MINOR form ie: nosetests-3.4. That means scripts (user scripts as well as spec files) have to change whenever we update python3 to a new major release. Having the major only form for all of these binaries will alleviate that. Packagers can just create a symlink if upstrean doesn't provide the -MAJOR version.
I do agree that we should have that, although you can now use nosetests-%{python3_version}.
<nod> -- yeah, that's what I use in spec files now. Unfortunately, spec macros aren't as helpful for the scripts that I have for building and testing my own projects.
Even in spec files, it's also an annoyingly long way to write "3.4" ;-)
-Toshio