Re: The future of src:ntp

[Guillem Jover <guillem@debian.org>]

On Mon, 2022-01-24 at 08:08:16 +0100, Guillem Jover wrote:
> On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote:
> > On 1/19/22 15:04, Bernhard Schmidt wrote:
> > > On 19.01.22 20:34, Richard Laager wrote:
> > > > 2. I create transitional binary packages in src:ntpsec:
> 
> > I got to thinking about this more. This won't work, because src:ntp is
> > 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of
> > 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's
> > transitional bin:ntp package to be newer than src:ntp's bin:ntp package.
> 
> Bumping the epoch to 2 here is completely gratuitous and can make a mess
> for ntpsec *and* potentially ntp iff upstream got to be improved and we
> wanted to reintroduce it in the future.
> 
> > It might be technically possible to build a binary package with different
> > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure
> > whether that's a good idea, especially compared to the alternatives.
> 
> Yes, this is the recommended method, that has been used in the past,
> and which is mentioned in the dpkg FAQ. You can set arbitrary versions
> via dpkg-gencontrol (or indirectly via dh_gencontrol).

To clarify, which seems I had included initially but removed while
editing. If generating the transition packages from ntpsec, then you
can set the binary versions, for example, to be something like:

  «1:$(ntp_upstream_version)+$(ntpsec_binary_full_version)»

so you'd end up with something like:

  1:4.2.8p15+dfsg+1.2.1+dfsg1-2
  1:4.2.8p15+dfsg+1.2.1+dfsg1-3
  1:4.2.8p15+dfsg+1.2.2+dfsg1-1
  …

and while ugly, it serves its intended purpose quite well w/o messing
with epochs and potentially muddling any package's future.

Thanks,
Guillem