Re: Epoch bump for kernelshark
On Tue, 2021-05-25 at 20:04:04 -0300, David Bremner wrote:
> Mattia Rizzolo <mattia@debian.org> writes:
> > On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote:
> >> On 5/23/21 8:34 AM, Sudip Mukherjee wrote:
> >> > And, as a result, upstream kernelshark is now at v2.0 but the Debian
> >> > packaged version is at v2.9.1 and I will need to add an epoch to the
> >> > version to package it directly from its new upstream repo.
> >> >
> >> > Current version: 2.9.1-1
> >> > Proposed version: 1:2.0-1
> >>
> >> How close is upstream to 3.0? If not close, are they willing to bump to 3.0
> >> anyway to avoid this versioning issue?
Not necessarily 3.0, just say 2.9.2 would be enough.
> > And in the meantime, I recommend you use 2.0-1 as source version, and
> > make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from
> > /usr/share/dpkg/pkg-info.mk)
I'd go with something like this too, given that the versioning has been
wrong all this time, so I don't see why it cannot be kept "wrong" until
the split package catches up with the old version.
> _If_ upstream is willing to do that, then great. Otherwise I don't see
> the problem with an epoch in this kind of situation. It's exactly the
> kind of change of versioning they were designed for.
Epochs are *always* problematic:
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F>
and I'd probably place this case it in the "acceptable with conditions",
where "conditions" would be "epoch does not seem necessary", given that
the versioning was correct upstream but was ignored all along, and the
versions are very close so it should be a reasonable matter of time to
catch up, even if upstream does not want to artificially bump it right
away.
Thanks,
Guillem
Reply to: