Re: using epoch to repair versioning of byacc package
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'
Reply to: