[WireGuard] The Distro Package Maintainers Thread

[Daniel Kahn Gillmor]

On Thu 2016-06-30 08:52:04 -0400, Jason A. Donenfeld wrote:
> So it looks like we're the distro people downstream of WireGuard:

hi all!

> Option a) monolithic:
>     Package name: wireguard
>
> Option b) split:
>     Tools package name: wireguard-tools
>     Module package name: wireguard _or_ wireguard-${SUFFIX},
>        where SUFFIX is modules, or dkms, or whatever the convention in
> your OS is

I prefer option (b)

> Zero dot zero. But it'd be nice to further specify that these are
> pre-release or experimental:
>
>     0.0.20160701_pre
>     0.0.20160701_experimental
>     0.0.20160701_killskittens
>
> Any preference on pre vs experimental vs killskittens vs something
> else? I'm open to anything here.
>
> The _suffix notation works well with how Gentoo does package versions.
> What about the rest of you? For example, I think this might pose
> problems:
>
>     0.0.20160701.pre
>     0.0.20160701.experimental
>     0.0.20160701.killskittens
>
> Or, if anyone has another idea for injecting a label like this into
> the snapshot revision, speak up.
>
> Overall, at the moment I'm leaning toward  0.0.20160701_experimental.
> But I'll wait for responses before deciding anything.

debian can't include an underscore (_) in the version number:

 https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

and while debian policy suggests that in some circumstances hyphen (-)
and colon (:) are OK, they really shouldn't be used either, so i'd
prefer the dot (.) or plus (+) as a delimiter.

For release candidates: on debian, we can use the ~ character to mean
"just before" -- so if you want a pre-release version (say "release
candidate 1 for 0.1") i'd normally declare the upstream version as
0.1~rc1, which will sort as "earlier" than 0.1 itself.

anyway, i won't lose much sleep over it -- i can translate whatever you
decide makes sense as an upstream version to whatever fits in debian,
with as minimal a change as possible.

One question though: how will the release version relate to
PACKAGE_VERSION in src/dkms.conf?  do we expect those to track each
other or are they separable?

> Regarding the topic of building infrastructure, it seems like with the
> exception of OpenWRT and Gentoo, everyone else is converging on DKMS?
> Is this right? If so, it appears that Christian's dkms.conf file is a
> good start for this, and I'll consider putting it directly in the repo
> at some point. Is anybody here well versed with DKMS? Does it have a
> way of expressing and warning about dependencies?

DKMS works fine for me; i'm sorting out some minimalist debian
packaging, and will start with Christian's dkms.conf, though i'm curious
how other folks would approach the module versioning, as i mentioned
above.

> === 5. Current Status ===
>
> In public repositories there are currently these:
>   https://aur.archlinux.org/cgit/aur.git/tree/?h=wireguard-git
>   https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/wireguard/

I'm going to be publishing debian packaging at:

  https://anonscm.debian.org/git/collab-maint/wireguard.git

I don't have anything to show there yet, but hopefully later today i'll
have something.

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