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.
- Needs to use dh-golang
- Needs to set Built-Using for the golang-petname package
- If I understand the import path correctly (github.
- Why do we skip the dh_strip step?
- Why do we ship the golang-petname package/executable? Isn't it redundant with the petname executable?
[1] http://