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
Attachment:
pgpvY5LcW1bQ2.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
