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