Package: debian-policy
Version: 4.7.0.0
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org
Dear Policymakers,
With the increasing amount of programs in Debian that Build-Depend and
statically link with Golang and Rust libraries, it's important that the
Debian Policy clearly sets out the requirements for declaring these
statically-linked libraries.
Currently, section 7.8 of the policy is a bit vague regarding stating static
libraries. It begins with saying:
Some binary packages incorporate parts of other packages when built but do
not have to depend on those packages. Examples include linking with static
libraries or incorporating source code from another package during the build.
It then states:
[The Built-Using field] should be used only when there are license or DFSG
requirements to retain the referenced source packages. It should not be added
solely as a way to locate packages that need to be rebuilt against newer
versions of their build dependencies.
This makes it seem that Built-Using shouldn't be used to declare
statically-linked dependencies, though that is not the case[1].
In early 2022, Guillem added support for a new Static-Built-Using field to
dpkg, encouraging packagers to use it over Built-Using to specify
statically-linked dependencies [2]. The commit message states the following:
This field mimics the previous Built-Using field semantics, but is
specifically intended for shadow dependencies stemming from static builds.
In Debian, the Rust and Go teams agreed to use this language agnostic field,
instead of one for each of the languages. This means it can be easily
supported by dpkg, and can be used by other languages and run-times.
This was also added to the deb-control(5) manpage, specifically differentiating
it from Built-Using as a field to be used "for static building purposes (for
example linking against static libraries, builds for source-centered languages
such as Go or Rust[...])".
The proposed change is to clarify and formally mandate the requirement to
declare statically-linked libraries used to build packages containing binaries
in Static-Built-Using. Attached is a draft patch of the proposed change.
Feedback is welcome!
Kind regards,
Maytham
[1]: The Go team requires that Built-Using is specified for packages containing
binary programs, and this is evident in the templates outputted by
dh-make-golang. (This is being migrated over to Static-Built-Using, the
correct field for this purpose.)
Similarly, the Rust team also requires that
Static-Built-Using are specified, as evident in debcargo's output when
generating d/control files. (X-Cargo-Built-Using is currently being used
but will soon be replaced by Static-Built-Using with the next upload.)
The Rust team also uses Built-Using when required, where dh-cargo/cargo
will check for and collate a list of any packages with copyleft licenses
in the dependency tree that require accompanying source.
[2]: https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=16c412439c5eac5f32930946df9006dfc13efc02
https://lists.debian.org/debian-devel-changes/2022/03/msg03007.html
From a9b9c513ae985fddca1bf9cceadce6d3d620ce53 Mon Sep 17 00:00:00 2001
From: Maytham Alsudany <maytha8thedev@gmail.com>
Date: Thu, 18 Apr 2024 22:29:01 +0300
Subject: [PATCH] Require use of Static-Built-Using to declare
statically-linked libraries
---
policy/ch-relationships.rst | 36 ++++++++++++++++++++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index fb9dae8..31a1757 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -666,8 +666,8 @@ dependency to install.
.. _s-built-using:
-Additional source packages used to build the binary - ``Built-Using``
----------------------------------------------------------------------
+Additional source packages used to build the binary - ``Built-Using`` and ``Static-Built-Using``
+------------------------------------------------------------------------------------------------
Some binary packages incorporate parts of other packages when built
but do not have to depend on those packages. Examples include linking
@@ -676,6 +676,9 @@ package during the build. In this case, the source packages of those
other packages are part of the complete source (the binary package is
not reproducible without them).
+``Built-Using``
+~~~~~~~~~~~~~~~
+
When the license of either the incorporated parts or the incorporating
binary package requires that the full source code of the incorporating
binary package be made available, the ``Built-Using`` field must list
@@ -710,6 +713,35 @@ requirements to retain the referenced source packages. It should not
be added solely as a way to locate packages that need to be rebuilt
against newer versions of their build dependencies.
+``Static-Built-Using``
+~~~~~~~~~~~~~~~~~~~~~~
+
+When a binary is statically linked to libraries in other packages and
+incorporated into the build process, the ``Static-Built-Using`` field must list
+the corresponding source package for these binary packages that were
+incorporated during the build, including an "exactly equal" ("=")
+version relation on the version that was used to build that version of
+the incorporating binary package.
+
+This is apparent in packages that incorporate Golang or Rust, which are
+statically-linked programming languages that use libraries' source code in
+building the target binary.
+
+A package statically linked with a library from the
+golang-github-mattn-go-xmpp-dev binary package would have this field in its
+control file:
+
+::
+
+ Static-Built-Using: golang-github-mattn-go-xmpp (= 0.2.0-1)
+
+A package statically linked with a library from the librust-gtk4-dev binary
+package would have this field in its control file:
+
+::
+
+ Static-Built-Using: rust-gtk4 (= 0.7.3-3)
+
.. [#]
The relations ``<`` and ``>`` were previously allowed, but they were
confusingly defined to mean earlier/later or equal rather than
--
2.39.2
Attachment:
signature.asc
Description: This is a digitally signed message part