Re: Debian part of a version number when epoch is bumped
On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote:
> On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin <firstname.lastname@example.org> wrote:
> > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> >> If Ubuntu uses an epoch without Debian following that decision, they can
> >> never sync with Debian again, increasing the maintenance burden
> >> indefinitely.
> > See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package
> > and fix the Depends line to use the package on Debian because of that).
> Would it hurt to take those epoch bumps into Debian?
Depends on what you mean by hurt. I see epochs being used w/o much
tought or care, on many situations where they are not supposed to be
used, and they are permanent stigmas. In addition to
also reset the monotonic versioning increment, marking version
barriers at which points making comparisons becomes useless.
IMO pushing epoch bumps upstream, or doing epoch bump races to compete
with external or third-party repositories (like what happened with the
debian-multimedia packages) would be a mistake, because as I mentioned
on that referenced mail, we'd be dependent on epoch blunders from all
our downstreams, and might end up with such a mess of our version
space to make it unusable.
> The background is that gcalctool 6.4 was renamed upstream to
> gnome-calculator 3.7. An overhauled upstream version numbering system
> seemed a pretty clear case for adding an epoch. A month after this
> landed in Ubuntu, the Debian packaging used a dh_gencontrol hack to
> only use an epoch for the transitional package gcalctool allowing the
> rest of gnome-calculator to avoid an epoch. Pretty cool trick except
> that it just causes extra work in Ubuntu multiple times a year.
This is not a hack, this is how it's supposed to be done. dpkg has
supported different source and binary versions for a very long time,
if not forever.