44 lines
2.1 KiB
Text
44 lines
2.1 KiB
Text
Support for build-drivers as alternatives to debian/rules
|
|
=========================================================
|
|
|
|
Status: draft, experimental
|
|
|
|
Summary
|
|
-------
|
|
|
|
This is currently an exploratory and experimental way to replace the current
|
|
debian/rules usage with alternative interfaces for building packages.
|
|
|
|
It relies on a new Build-Driver field honored by dpkg-buildpackage, but that
|
|
might eventually disappear or change semantics.
|
|
|
|
Background
|
|
----------
|
|
|
|
Our current packaging methods are built around the concept of a Makefile
|
|
(debian/rules), which must contain every bit of logic needed to produce
|
|
debs. Historically, this involved duplicating various runes in every
|
|
package and then spending decades updating the runes in every package
|
|
as we got wiser. Over time there have been many attempts to centralize
|
|
these runes in package helpers such as debstd (obsolete), dbs (obsolete),
|
|
yada (obsolete), debhelper (still in use) and cdbs (still in use).
|
|
|
|
Despite these improvements, our state of the art packaging flow suffers
|
|
from this awkward "assume-nothing-do-everything" design. There are many
|
|
cases where dpkg has the only "official" tools to implement a feature
|
|
(e.g. dpkg-gencontrol and dpkg-deb), but we still expect that the helper
|
|
tools manage all orchestration of calling these tools in the right order.
|
|
Furthermore, the "Makefile as an entry point" also neuters any efficient
|
|
communication between dpkg tools and the underlying helper, as it
|
|
introduces an impedance layer which forces us to reparse the same files
|
|
multiple times, does not make it possible to guarantee a sanitized build
|
|
environment for the packaging, complicates our ability to enable certain
|
|
features transparently or (in debhelper's case) via compat bumps, and
|
|
also forces us into imperative packaging flows (making it difficult for
|
|
lintian to spot issues). As "recent" examples we can mention "build-arch"
|
|
targets, updating XXFLAGS to include basic hardening, and the
|
|
Rules-Requires-Root field.
|
|
|
|
All of these things complicate the lower packaging stack, inhibits our
|
|
ability to deploy various performance optimizations and neuters our
|
|
ability to make packaging simpler.
|