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.
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.
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.
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.
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.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:06:46 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |