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

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmHtfH8ACgkQzCr0RyFn vgNV8gv9E9djweR5brJ2SPSb7dUvHyQNCEncp/j4vgbvHkXsh+2XsS4sAMGxb21N DTJJ222uuVU57LHZLu7s82Fu1KcKDb8jzso5xXU5NaCE8Q8apmPVhe9CtoAV3TPx v9Nyqwg0xirMJzlCUT4CD8Mjo7H3pyeuM+0DphOAosdmt/5GDs4p6PBZ2zN/gvMe PDrZzONLd0OMa0TYgRsP7T548U817oKrCZAh4VlSRyJq+bcIL6MyN0pbbnlA3lnL 6UPAxuntqss5ye61Jfy/CJXw1Dlajl6al2EvVxCfY4v+sEzg3U2qChr2efZwpcuJ wLwVduk2XsE7Yu0YkQtL5hDD1fE365znRR+N0drwYr64LnpnRCt2RvtpEDHgjQZv 9cD1tT34IHvro6Wf8AFGXUyokP50e7ghSQVhxvKrEUxY9FcL7ITZwaNpsEbUg0dj cEY8aXIm6UtrWqk1VO8rxCRP7QAwkFwJgaC3hu0SGOGqU1aTpWhYKrGUzW9GXOA7
qAoH7cca
=r7Ne
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------44HPTLjH2QOKJLZATiAVoLjE
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMS8yMy8yMiAxMDowNCwgVGhvbWFzIERpY2tleSB3cm90ZToNCj4gSW4gIzEwMDM3Njks IEFuZHJlYXMgTWV0emxlciB3cm90ZToNCj4+IDEuIFRoZSB1cGxvYWQgaW50cm9kdWNlcyBh biBlcG9jaCBiZWNhdXNlIHRoZSB1cHN0cmVhbSB2ZXJzaW9uIHdlbnQgZnJvbQ0KPj4geXl5 eW1tZGQgdG8gMi4wLnl5eXltbWRkLiBHaXZlbiB0aGF0IHRoZSBuZXcgdmVyc2lvbiBzY2hl bWUgc2VlbXMgdG8NCj4+IGhhdmUgZm91bmQgYWNjZXB0YW5jZSBpbiBlLmcuIEZlZG9yYSAv SS8gZG8gbm90IHNlZSBhIGJldHRlciB3YXkuIENvdWxkDQo+PiB5b3UgYXNrIGFib3V0IHRo ZSBlcG9jaCBvbiBkZWJpYW4tZGV2ZWwgKGFzIHBlciBwb2xpY3kNCj4+IGh0dHBzOi8vd3d3 LmRlYmlhbi5vcmcvZG9jL2RlYmlhbi1wb2xpY3kvY2gtY29udHJvbGZpZWxkcy5odG1sI2Vw b2Nocy1zaG91bGQtYmUtdXNlZC1zcGFyaW5nbHkNCj4+ICkgLSBUSUEuDQo+IA0KPiBBcyBi YWNrZ3JvdW5kLCBieWFjYyB3YXMgcGFja2FnZWQgYnkgRGF2ZSBCZWNrZXQgaW4gMjAwNSwg c3dpdGNoaW5nDQo+IHRvIG15IGZ0cCBhcmVhIGFzIHVwc3RyZWFtLiAgSW4gZG9pbmcgdGhh dCwgdGhlIHZlcnNpb25pbmcgb2YgdGhlDQo+IHBhY2thZ2UgY2hhbmdlZDoNCj4gDQo+IGZy b20NCj4gCS0tIExhTW9udCBKb25lcyA8bGFtb250QGRlYmlhbi5vcmc+ICBGcmksIDI2IE5v diAyMDA0IDE4OjQ5OjA5IC0wNzAwDQo+IAlieWFjYyAoMS45LjEtMSkgdW5zdGFibGU7IHVy Z2VuY3k9bG93DQo+IHRvDQo+IAktLSBEYXZlIEJlY2tldHQgPGRham9iZUBkZWJpYW4ub3Jn PiAgU3VuLCAxNCBBdWcgMjAwNSAxMDoxNDoxMiArMDEwMA0KPiAJYnlhY2MgKDIwMDUwNTA1 LTEpIHVuc3RhYmxlOyB1cmdlbmN5PWxvdw0KDQpJIHNlZSBubyBvdGhlciB3YXkgdG8gY29y cmVjdCB0aGlzIGJ1dCB0byBhZGQgYW4gZXBvY2guDQoNCkFzIHdlIHNlZSBpbiB0aGlzIGNh c2UsIHN3aXRjaGluZyBmcm9tIHZlcnNpb24gbnVtYmVycyB0byBkYXRlLWJhc2VkIA0KdmVy c2lvbnMgaXMgZGFuZ2Vyb3VzIGJlY2F1c2UgaXQncyBpbXBvc3NpYmxlIHRvIGdvIGJhY2sg d2l0aG91dCBhbiANCmVwb2NoLiBBIGJldHRlciB2ZXJzaW9uIHdvdWxkIGhhdmUgYmVlbiBz b21ldGhpbmcgbGlrZSAxLjkuMSsyMDA1MDUwNS4NCg0KTGludGlhbiBmbGFncyBvbiB0aGlz LCBidXQgKGFjY29yZGluZyB0byB0aGUgbmFtZSBhbmQgZGVzY3JpcHRpb24pIG9ubHkgDQpm b3IgbmV3IHBhY2thZ2VzOg0KaHR0cHM6Ly9saW50aWFuLmRlYmlhbi5vcmcvdGFncy9uZXct cGFja2FnZS11c2VzLWRhdGUtYmFzZWQtdmVyc2lvbi1udW1iZXINCg0KUGVyc29uYWxseSwg SSdkIGxpa2UgdG8gc2VlIHRoYXQgbGludGlhbiBjaGVjayBmaXJlIGlmIHRoZSBkYXRlLWJh c2VkIA0KdmVyc2lvbmluZyBpcyBuZXcuIFRoYXQgaXMsIGl0IHNob3VsZCBmaXJlIGlmIHRo ZSBwcmV2aW91cyBjaGFuZ2Vsb2cgDQplbnRyeSBkaWQgbm90IGhhdmUgYSBkYXRlLWJhc2Vk IHZlcnNpb24uDQoNCkV2ZW4gYmV0dGVyIHdvdWxkIGJlIGEgZGFrIChvciB3aGF0ZXZlciBm dHAtbWFzdGVyIHRvb2wgaXMgcmVsZXZhbnQpIA0KaGFyZCBmYWlsIGlmIGdvaW5nIGZyb20g bm9uLWRhdGUtYmFzZWQgdG8gZGF0ZS1iYXNlZCBhdCB0aGUgZnJvbnQgb2YgdGhlIA0KdmVy c2lvbiBzdHJpbmcuDQoNCi0tIA0KUmljaGFyZA0K

--------------44HPTLjH2QOKJLZATiAVoLjE--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAmHtwMsACgkQ+HlhmcBF hs43Ug/+IX5uWP4CdZutGMsAHKIkeFPIkT0wAUuYm0+KKTlocUEphxzpgOoNzWz5 oZXJZ91KnUSrvTHBYAKIuZi4q7JnRCin/q+5oQac0OBkHP1XpvL9kFKV1tJ2LEco 5BcJ6uOxEuyWYTpuJPI+oLoixP9w0g+ec7pZYRJXqoRdow5wwjDnLuGnlq6ZiSQ4 t9wCgEPAp954RLxITLYdT8JdsO7XQaE3poKCEThMcmAZJA+1pxUZ81nKxSyAdL5V i/MrVM+1Ex9Z23whZDBHxsoTT7stygQA1Xlf0WNV7LwZ/YYY+tHci69RDYO8fl5G tSGLgvtzGgVFgEduGzSLX8Ab/RQCrlkHpePKFMuFc0Ik7kx0y/ydJpMRfxJbb81n spaWDkkedKO2aYG2pKRdhsOBfaYVZxokSSMl2TTLzFZOxPYcnAaBaPzO6aFzGnLB tn4/JdxINAKUisPVDKa0e6DiePzMJC/xHyE2I2KsxGpBhVw9pqHLepumDks616Vw Iwmu1cof2uhg7wGaKyuHEtxsbd0YMDazZW0wmL2saf5hxctzRi/3XlkKpg2GBHzZ PCsGgcm0tZ0mMw4sHIsUIeXhdpYvu0bKuUC1Qa8q3rIKnxLMUfnrbEY9/CTy1Twm mNkJMRQKaVVqahPNlJtXMwWEq7Uf7orjIRTJLv8ke6a/JXJMXwg=
=NKz1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Date: Sun, 23 Jan 2022 14:55:39 -0600
From: Richard Laager <rlaager@debian.org>
To: debian-devel@lists.debian.org
Subject: Re: using epoch to repair versioning of byacc package

On 1/23/22 10:04, Thomas Dickey wrote:

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

I see no other way to correct this but to add an epoch.

agreed. Is there some way to further improve the transition?

As we see in this case, switching from version numbers to date-based
versions is dangerous because it's impossible to go back without an epoch. A better version would have been something like 1.9.1+20050505.

I suspect that providing an interim 1.9.1+20140715 with/without an epoch
would have problems going backward. But there might be some way to do that.

Lintian flags on this, but (according to the name and description) only for new packages: https://lintian.debian.org/tags/new-package-uses-date-based-version-number

Personally, I'd like to see that lintian check fire if the date-based versioning is new. That is, it should fire if the previous changelog entry did not have a date-based version.

yes... but it's a little late for that (I've only learned about these
issues in the process of setting up the upgrade).

Even better would be a dak (or whatever ftp-master tool is relevant) hard fail if going from non-date-based to date-based at the front of the version string.

--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmHtzAcACgkQzCr0RyFn vgNVeQv+Jxcganbledcb4Lmf4ADOqnbj29l5k+Or7MvMz7MdUHTu0bfirlCJofWl 5z73N8e5vaUELCfjOx98hk4JFfLV2u5ooh5ihsum3Jy0uacVhnuff5tQmteeEQgi w8sEs7ckQe7ysW/oar1DNQex3GLfBuGeTy45Kf6mgCnV4JAZhh0lS/wjWWNRw84c TXj4FH5gEy7SqrJNDwxiGAPvTNCzZqagYb8kg2ln9haIPDzGfOqsPTL7jK/Rpzcj 88CRR+5rPlbrkLE0n1w5D0OrSbMuB8mDV4Ikttkk0sE8oCmfO6GKzmzPo/BySZmx +8Qy2KWpZaPrVTM0Nr5d9X2n5tUcUDAxl7uEPUbRxKY3dWL9UymjvOfXmKuTiVAZ UYVLLBtXtBthDpDbgL0swAdyRLQKz1vK+UPBMj02gCARrdupmiBKcY4xan4PUNcW /HmVA2gAxzRbO7QiYi8qC+zjkmYBKLPFGTteS7lBGFlPyBCsB1clC/iPpLVXlQLa
QsuFyzs9
=1OpN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-01-23 Thomas Dickey <dickey@his.com> wrote:

From: Richard Laager <rlaager@debian.org>

On 1/23/22 10:04, Thomas Dickey wrote:

[...]

I see no other way to correct this but to add an epoch.

agreed. Is there some way to further improve the transition?

As we see in this case, switching from version numbers to date-based
versions is dangerous because it's impossible to go back without an
epoch. A better version would have been something like
1.9.1+20050505.

I suspect that providing an interim 1.9.1+20140715 with/without an epoch would have problems going backward. But there might be some way to do that.

[...]

Hello,

afaiui Richard was pondering the time machine solution - Whether the
2005 upload should have have used 1.9.1+20050505 instead of 20050505. It
is not a viable solution anymore.

Lintian flags on this, but (according to the name and description) only for >> new packages:
https://lintian.debian.org/tags/new-package-uses-date-based-version-number

Personally, I'd like to see that lintian check fire if the date-based
versioning is new. That is, it should fire if the previous changelog entry >> did not have a date-based version.

yes... but it's a little late for that (I've only learned about these
issues in the process of setting up the upgrade).

Even better would be a dak (or whatever ftp-master tool is relevant) hard
fail if going from non-date-based to date-based at the front of the version >> string.

It might help a little bit but I suspect that very often at the time the
upload with the date-based version hits the Debian archive the version
number is already entrenched. - There might have been lengthy
discussions before or packages with the new numbering have been shipped
at other places like other major distros.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)