Changes to build-dependency handling in Ubuntu xenial beyond
steve.langasek at ubuntu.com
Fri Apr 8 16:39:10 UTC 2016
For some time now, we've recognized that the process of separating packages
between main and universe was causing some drag on Ubuntu development.
Because "main" has covered build-dependencies in addition to dependencies,
all of the process around promoting packages to main - security review,
checking for duplicated functionality, patching packages to remove
dependencies that we don't want to support, and so forth - has been applied
not just to packages that are going to be installed on users' systems, but
also to packages that are used at build time and have no impact at run time
for the vast majority of users.
We've recently seen the build dependencies of supported packages expand to
include a great number of language runtimes, for instance; including
runtimes that we know we would not be able to provide security support for
over the lifetime of 16.04 LTS. As a result, starting at the last UOS in
November, we've been discussing a change to the definition of main before
16.04 LTS, to refocus our efforts on the packages that we know matter most
to our end users.
Thanks to some stellar work by Dimitri Ledkov and Colin Watson, and as
discussed on ubuntu-devel over the past couple of months[1,2], a change has
been landed to Launchpad and the archive reports to allow packages in
main to build-depend on universe (and packages in restricted to build-depend
on either universe or multiverse).
As a result, the archive admins will be moving a large number of packages
from main to universe over the next few days in preparation for the 16.04
What this means for you:
- If you are building packages locally, you will want to update your build
environments for xenial and beyond to include universe in the apt
sources, to mirror Launchpad's behavior.
- If you are updating a package that carries a delta to its
build-dependencies, you will want to check if this delta can now be
dropped. If readding the build-dependency results in a new runtime
dependency, the package will be blocked by proposed-migration in
-proposed until component mismatches are resolved; you will then need
to either re-add the delta, or follow the MIR process.
- If you have a package whose source has been split into separate main and
universe source packages, this split can now be dropped with the next
- If there is a package that was up to now only in main because of
build-dependencies, but your team is committed to supporting it, you will
want to add it explicitly to the seeds to keep it from being moved to
- If you have a build-dependency which does not result in a runtime
dependency, but *does* result in code being copied into the final
package, you must ensure that this code copying is declared using the
Built-Using header. (This is an uncommon case; the vast majority of
the affected packages are written in go, where our package toolchain
handles this automatically today.)
Other than that, we expect this to be a fairly uneventful transition, and
hope you find the new rules simplify your Ubuntu development work at least a
Onward the xenial release!
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek at ubuntu.com vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the ubuntu-devel-announce