[MIR] golang-dbus-dev

[Stéphane Graber]

Please note that the notes below solely apply to the -dev package as that's the only one we require for LXD and so the only one we are looking at getting into main.
If the source package produces other packages, binary, documentation or other, those can stay in universe.

Due to the high number of packages that LXD need to see promoted, the content below was made to be generic and apply to all packages we'd like to see promoted.
The information in it is accurate, in that it was checked individually for all packages before filing the bug report.

[Availability]
Source-only package currently available in universe.

[Rationale]
Build-dependency for LXD once we stop bundling the dependencies in our source package.
See LP: #1507156 for details.

[Security]
This is a source package which will only be used by other Go projects that build-depend on it.
Standard practices in the Go ecosystem unfortunately is not to do any release/tag, nor publish changelogs, bugfix announcements or other advisory information.
Most of those projects will therefore have a 0.0+git-hash kind of version scheme for their packaged form.
Update to those will typically be a completely new snapshot and refresh of their downstreams to match or be a one-off cherry-pick after a specific issue is reported.

CVEs: none
Source-only so none of the binary checks apply.

[Quality assurance]
Source-only, arch:all package so most of the points do not apply.
There are currently no bug reports filed against this source package.
The package is either maintained in Debian or maintained by its upstream directly in Ubuntu.
Most of those packages do not have a debian/watch file due to their upstream never pushing out versioned releases.

[UI standards]
Not applicable

[Dependencies]
We are only interested in the -dev source-only package.
None of those have build-dependencies due to being source-only.
Any needed dependency is already in main or covered by a separate MIR.

[Standards compliance]
All of those packages meet some version of the Debian golang packaging policy. Some using older name patterns, some using newer ones as the golang packaging team is transitioning them progressively.

[Maintenance]
All except one (petname) are coming from Debian and are maintained there.
The Ubuntu LXC team has been subscribed to all bug mails for all packages which we are requesting promotion into main.

[Background information]
All of those MIRs are being filed at the request of the Canonical Security team as a requirement for the supportability of LXD in main for 16.04 LTS.

Note that LXD upstream will keep bundling its dependencies in release tarballs as due to the rather odd way the go ecosystem works, it's the only way for us to absolutely guarantee that what we tested upstream will keep on building and working as expected.
The Ubuntu packaging will simply ignore the "dist/" directory in our release tarball and use the packaged dependencies instead. Backports and PPA uploads will not use the packaged dependencies and instead will use the bundled ones as backporting over 15 packages without breaking any other user of said packages in a world where there is no API/ABI guarantee, just isn't doable.

[Stéphane Graber (stgraber)]

I just noticed we forgot this one in our batch of MIRs, it's a build-depends and depends of goalng-github-coreos-go-systemd.

It's still using the old naming but is in sync with Debian with stuff build-depending or depending on it, so I don't think we should try to change things in Ubuntu and just let Debian deal with the eventual rename.

[Michael Terry (mterry)]

For sure, agreed that we don't want to move ahead of Debian on renames.

This looks fine, except that it doesn't run its tests. Much like golang-systemd, its tests require a running service (in this case, dbus). Can we just build-dep on dbus or add a simple autopkgtest that runs the go tests?

[Stéphane Graber (stgraber)]

I'll take a look, this one should be much easier than the systemd one in that it should just require a dbus daemon, it probably doesn't actually try to talk to a running root-owned daemon :)

[Stéphane Graber (stgraber)]

Testsuite can't be run on the buildd due to depending on access to the system bus (so needs root), but autopkgtest should be possible, testing that now.

[Stéphane Graber (stgraber)]

Got it working in autopkgtest, updated source package uploaded to the archive, moving back to triaged.

[Stéphane Graber (stgraber)]

binary and its source have been promoted to main, closing.