decoupling version dependencies from metapackage in debian/ubuntu?

[Jason A. Donenfeld]

Hey Daniel,

> 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.

Ahh, interesting. I'm surprised there isn't an atomic replacement that
occurs only once all dependencies and reverse dependencies are
resolvable.


> 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?

This all sounds good and reasonable to me. My intention is that the
current Netlink API _is_ stable. I had the Netlink maintainer take a
look at it before it went live, and things checked out, and now
systemd-networkd is using it, so the idea here is that that API is a
stable one. If for whateverunfortunatereason it did break, this would
of course be a sufficiently large deal that I'd go through the pains
of multiparty notification, coordination, and such.

Jason