From 44cf9c6d2d274eac37502e835155f7e985f1b8e6 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 7 Aug 2024 15:30:08 +0200 Subject: Adding upstream version 1.22.7. Signed-off-by: Daniel Baumann --- doc/spec/build-driver.txt | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 doc/spec/build-driver.txt (limited to 'doc') 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. -- cgit v1.2.3