Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Egbert Verhage <egbert@eggiecode.org>,
	Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: decoupling version dependencies from metapackage in debian/ubuntu?
Date: Fri, 19 Jan 2018 14:21:42 +0100	[thread overview]
Message-ID: <CAHmME9rU+n6bMB+eYKu74yVn2bNkMJLX=FP-XbfKt+qjsoTVYQ@mail.gmail.com> (raw)

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

             reply	other threads:[~2018-01-19 13:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19 13:21 Jason A. Donenfeld [this message]
2018-01-19 13:30 ` Jonathon Fernyhough
2018-01-19 19:24 ` Egbert Verhage
2018-01-20  4:42 ` Daniel Kahn Gillmor
2018-01-20 12:19   ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHmME9rU+n6bMB+eYKu74yVn2bNkMJLX=FP-XbfKt+qjsoTVYQ@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=dkg@fifthhorseman.net \
    --cc=egbert@eggiecode.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).