decoupling version dependencies from metapackage in debian/ubuntu?

[Daniel Kahn Gillmor]

Hi Jason--

On Fri 2018-01-19 14:21:42 +0100, Jason A. Donenfeld wrote:

> Someone in #wireguard is getting weird errors about version
> dependencies between packages. I started looking into it and noticed
> the strong coupling between the metapackage version and the other two
> packages' versions.

I added the tight versioning to the metapackage when i realized that
divergent versions of the wireguard-dkms and wireguard-tools actually
wouldn't be an acceptable combination.

> The users' issue seems mostly like an Ubuntu problem: they build _all,
> _amd64, and _x86 immediately, but delay the other architectures until
> later. So, the user in #wireguard was using an aarch64 board, which
> pulled in the newer _all package, but that package was unable to
> subsequently satisfy its architecture-specific dependencies, since
> they hadn't been built yet. Annoying Launchpad bug; news at 11.

as explained earlier, this isn't a launchpad bug, it's a function of
running with a rolling distribution (debian unstable and ubuntu PPAs
both have this characteristic), where there is no coordinated
cross-platform release schedule.

This means that for some architectures, there will be some times when a
package isn't fully-installable if there are cross-arch dependencies.
the usual answer is "wait a day for the builder you care about to catch
up".  Some repos will also keep around two versions of the same package
in an archive if they know that the situation exists, but i'm not sure
what configuration is need of the archive (or of the inter-package
dependencies) to make that happen.

While the above situation is a little annoying, it does only affect
new installations; automatic upgrades will simply hold off until all the
necessary package version/arch combinations are alignted.  that said …

> But regardless of Launchpad particularities, I was wondering what the
> motivation is for coupling versions together.

i started with the tight versioning because it seemed simpler as an
implementation and wouldn't require me to coordinate with any particular
upstream interface changes, but i readily concede that this isn't a
strong motivation.

> Since the Netlink changes, there should be compatibility between the
> tools and the module. Does that mean it's not useful for the
> metapackage to do strong coupling?

If the netlink interface is actually stable, then at least as simple as
the current arrangement (and probably more robust) to instead set up the
dependency versioning to be at least the first version of both packages
which agree to the stable netlink interface contract.

I know that we moved from ioctl to netlink in 0.0.20171001 -- was the
interface fully stable already by that snapshot?  if so, then i'd just
change those metapackage dependencies to (>= 0.0.20171001) and assume
that mixing and matching anything beyond that point is an acceptable
choice for the package resolver.

if i do that, i'd ask you to be really clear and explicit in each new
snapshot if you think it introduces a backward-incompatible interface on
either side of the netlink boundary.  if that happens, it's not the end
of the world, i just want to be aware of it so that i can explicitly
bump the dependency threshhold in the metapackage.

what do you think?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180119/34b766b8/attachment.asc>