decoupling version dependencies from metapackage in debian/ubuntu?

decoupling version dependencies from metapackage in debian/ubuntu?

[Jason A. Donenfeld]

Hey Egbert, Daniel,

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.

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.

But regardless of Launchpad particularities, I was wondering what the
motivation is for coupling versions together. 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? Or is there some other factor this is accounting for
that I don't know about.

(Apologies in advance if I've managed to misunderstand dpkg again.)

Jason

Re: decoupling version dependencies from metapackage in debian/ubuntu?

[Jonathon Fernyhough]

[-- Attachment #1.1: Type: text/plain, Size: 517 bytes --]

On 19/01/18 13:21, Jason A. Donenfeld wrote:
> The users' issue seems mostly like an Ubuntu problem: they build _all,
> _amd64, and _x86 immediately, but delay the other architectures until
> later.

Just for pedantic correctness, packages are built as and when builders
[1] become available (+/- some "special sauce" [2]); there are fewer
non-x86 builders so packages take longer to work through the queue.


J

[1] https://launchpad.net/builders
[2] https://help.launchpad.net/Packaging/BuildScores


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: decoupling version dependencies from metapackage in debian/ubuntu?

[Egbert Verhage]

On Fri, 2018-01-19 at 14:21 +0100, Jason A. Donenfeld wrote:
> Hey Egbert, Daniel,
> 
> 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.
> 
> 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.

This sucks and most strangest about it that it states that it starts in
17 hours.
https://launchpad.net/~wireguard/+archive/ubuntu/wireguard/+build/14252
241

Even with a simple test on my personal PPA is states that I starts in
20 hours. 

> 
> But regardless of Launchpad particularities, I was wondering what the
> motivation is for coupling versions together. 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? Or is there some other factor this is accounting for
> that I don't know about.
> 

If you want the merge the 2 packages it can be a bit tricky.
First of you need to remove the old packages wireguard-dkms and
wireguard-tools by the next upgrade and sure not the overwire any
config and not to create conflicts with the old dpkg package.

Second thing is that not everybody installs dkms and tools package, for
example in a lxd containers I only install wireguard-tools to init a
wireguard interface.

Besides that packages like virtualbox have a extra package for dkms if
what that, it does not depend on the dkms package.

Maybe for now remove the metapackage in the PPA?

Greetz,
Egbert

Re: decoupling version dependencies from metapackage in debian/ubuntu?

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: 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