In #1003769, Andreas Metzler wrote: > 1. The upload introduces an epoch because the upstream version went from > yyyymmdd to 2.0.yyyymmdd. Given that the new version scheme seems to > have found acceptance in e.g. Fedora /I/ do not see a better way. Could > you ask about the epoch on debian-devel (as per policy > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly > ) - TIA. As background, byacc was packaged by Dave Becket in 2005, switching to my ftp area as upstream. In doing that, the versioning of the package changed: from -- LaMont Jones <lamont@debian.org> Fri, 26 Nov 2004 18:49:09 -0700 byacc (1.9.1-1) unstable; urgency=low to -- Dave Beckett <dajobe@debian.org> Sun, 14 Aug 2005 10:14:12 +0100 byacc (20050505-1) unstable; urgency=low My (upstream) byacc tarballs have been named according to the patchdate. The program itself identifies with the complete version using "-V" option, which I added a few months before the Debian package change: 2005-05-04 Thomas E. Dickey <dickey@invisible-island.net> * yacc.1: add -V option * main.c: add -V option to print the version. simplify option-parsing by moving the duplicate logic for setting flags into new function setflag(). * skeleton.c: move the actual definition of YYMAJOR and YYMINOR to defs.h (as numbers). add YYPATCH here so it can be tested by applications. * defs.h: add macros to define VERSION in terms of the (numeric) YYMAJOR, YYMINOR and YYPATCH symbols. * lalr.c, lr0.c, mkpar.c, defs.h, closure.c, warshall.c, output.c, symtab.c: reduce externs by making static the procedures that are not referenced outside the module in which they are defined. * makefile.in: the VERSION file holds the patch-date. Define YYPATCH, so this will be compiled into the skeleton. * VERSION: patch-level for byacc The policy cited above says Note that the purpose of epochs is to cope with situations where the upstream version numbering scheme changes and to allow us to leave behind serious mistakes. If you think that increasing the epoch is the right solution, you should consult debian-devel and get consensus before doing so (even in experimental). The version policy here: https://www.debian.org/doc/debian-policy/ch-controlfields.html#version says The version number of a package. The format is: [epoch:]upstream_version[-debian_revision]. epoch This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. Epochs can help when the upstream version numbering scheme changes, but they must be used with care. You should not change the epoch, even in experimental, without getting consensus on debian-devel first. upstream_version This is the main part of the version number. It is usually the version number of the original (“upstream”) package from which the .deb file has been made, if this is applicable. Usually this will be in the same format as that specified by the upstream author(s); however, it may need to be reformatted to fit into the package management system’s format and comparison scheme. The upstream version number (which is displayed using the "-V" option) shows the full version rather than the patchdate used for naming the tar files, e.g., byacc - 2.0 20220114 At the time Becket switched to my version of byacc, that would have printed byacc - 1.9 20050505 Since then, a) Dave Becket stopped maintaining the package (in 2014), and b) I released byacc 2.0 (September 10, 2019), to account for integrating the back-tracking feature beginning in 2014. Having Debian's package so far out of date is a nuisance, and on being reminded of this a few months ago, I decided to update the package. The Debian policy quoted above seems to assume that the Debian package is good, and that some allowance must be made for problems in upstream. However, it isn't that simple. Upstream identified the version in a conventional manner, but not in a manner which the packager noticed or found convenient for packaging. The upstream versioning scheme has not changed -- but the package version does not use upstream's version. Just changing this is also not simple. Adding the full (1.9 or 2.0 version to the Debian package runs into the problem that in Debian, "2.0.20220114" is less than "20140422" because "2" is the part that apt uses for comparison. The Debian-style workaround for this is to add an epoch, which I have done in https://mentors.debian.net/package/byacc/ -- Thomas E. Dickey <dickey@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net
Attachment:
signature.asc
Description: PGP signature