Adding upstream version 1.22.7.upstream/1.22.7

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 44 insertions, 0 deletions

diff --git a/doc/spec/build-driver.txt b/doc/spec/build-driver.txt
new file mode 100644
index 0000000..683c093
--- /dev/null
+++ b/doc/spec/build-driver.txt
@@ -0,0 +1,44 @@
+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.