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:
1) sphinx-build-v0.93.4 would be very confusing (I do understand that this
is a downstream problem, but see the following point)
2) 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