Hi everyone,
Thanks for your input and suggestions. I've attached an updated patch with
several changes, including improving making the description of the field more
specific, adding another example that is not Go/Rust related, and improving the
Rust example to show the simultaneous use of Static-Built-Using and Built-Using.
I would greatly appreciate any more feedback for this new patch. If you believe
that it is complete (and you are a DD), it would be very helpful if you could
second this consensus and proposal.
The relevant part of the new patch has been included at the bottom of this
email.
On Fri, 19 Apr 2024 at 10:18 +0200, Simon Josefsson <simon@josefsson.org> wrote:
> I think there is a gap between "statically linked libraries" and "builds
> for source-centered languages" -- could it be clarified if
> Static-Built-Using is intended to cover situations where package A
> incorporate source code from package B and source code from B affects
> whatever goes into the binary package of A? That is definitely true for
> statically linked libraries.
Yes, that is the intention, and the updated description should reflect that.
> I'm thinking of how gnulib C code is included in many packages, which
> could be set up to work in a way similar to how Go packages work. I
> just made 'libntlm' use the 'gnulib' package this way, to reduce
> xz-related risks with vendored gnulib code. Should libntlm's
> debian/control now include a 'Static-Built-Using: gnulib'?
I believe so. There are a lot of packages that would need cleaning up after
this proposal is implemented.
On Sat, 20 Apr 2024 at 20:23 +0200, Guillem Jover <guillem@debian.org> wrote:
> As mentioned before I think the currently proposed description is too
> restrictive and specific to Go and Rust, and it should be expanded.
The updated description should be better now, thanks for your feedback.
> The example usage seems also too specific, and might lead people to think
> this is the only valid use, and their placement feels a bit odd, perhaps
> these should be given as a footnote? (But this is really for the Policy
> editors to decide.)
I've expanded the example usage by also adding a sans-Go/Rust example. I've
placed the Static-Built-Using examples in the same way as the examples for the
Built-Using field.
On Tue, 23 Apr 2024 at 21:02 +0200, Fabian Grünbichler
<debian@fabian.gruenbichler.email> wrote:
> Speaking for the Rust side - I'd say they match our expected usage of
> the field. A slight rephrasing of "linked to libraries in other
> packages" might match it even better, since in Rust's case, we are
> usually talking about linking to libraries compiled from sources shipped
> in other packages (librust-X-dev only contains the sources and possibly
> helper scripts needed to build them, but not the compiled library).
>
> But it also covers static linking of native libraries, so the current
> phrasing matches that. Might be bikeshedding/nitpicky though ;)
Updated phrasing should address this.
> On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote:
> > My immediate question is why the Haskell and OCaml team's approaches,
> > were not copied. They seem to work well and don't require a new field.
> > That seems worth writing down.
>
> I am not sure about the details of their approach... are those available
> somewhere?
I am also unsure about this, and wonder whether this is necessary since Haskell
and OCaml are completely different languages with their own approaches.
On Wed, 24 Apr 2024 at 15:30 +0100, Peter B <peter@pblackman.plus.com> wrote:
> Perhaps Pascal & Lazarus could be added to that list for clarity?
I'm unfamiliar with how the buildsystems for these languages work, so I would
appreciate it if you could suggest a specific phrase to add to the list of
scenarios. Even better if you could come up with an example to add at the bottom
:)
Below is the relevant part of the updated patch, to save you from downloading
the attachment:
``Static-Built-Using``
~~~~~~~~~~~~~~~~~~~~~~
This ``Static-Built-Using`` field must list source packages who's
contents (like source code or data) were incorporated into the binary
package during the build, including an "exactly equal" ("=") version
relation on the version that was used to build that version of the
incorporating binary package.
Cases where this field may be used include (but are not limited to)
linking against static libraries in other packages, builds for
source-centered languages such as Go and Rust, usage of header-only
C/C++ libraries and injecting data blobs into code.
This is useful to track whether the package might need to be rebuilt
when source packages listed here have been updated. This is important
to stay ahead of the package failing to build from source (FTBFS) with
the updated versions of the listed source packages, or security
updates in the listed source packages.
Unlike Built-Using, the Debian archive will **not** retain the
versions of the source packages listed in the Static-Built-Using
field. This means that any package listed in Static-Built-Using who's
license requires its source code to be available must also
simultaneously be listed in the Built-Using field.
A package that needs domain name suffix data from the publicsuffix
binary package would list it in the ``Static-Built-Using`` field like
so:
::
Static-Built-Using: publicsuffix (= 20231001.0357-0.1)
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 the libraries contained in the
librust-gtk4-dev and librust-pulsectl-rs-dev binary packages, where
the latter is licensed under GPL-3+ (a license that requires full
source code to be available), would have these fields in its control
file:
::
Built-Using: rust-pulsectl-rs (= 0.3.2-1+b1)
Static-Built-Using: rust-gtk4 (= 0.7.3-3), rust-pulsectl-rs (= 0.3.2-1+b1)
--
Kind regards,
Maytham
From 06cf64756ff1ee66d845e86dcf5c9dafd4a84b39 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 | 60 +++++++++++++++++++++++++++++++++++--
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index fb9dae8..636e2a5 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,59 @@ 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``
+~~~~~~~~~~~~~~~~~~~~~~
+
+This ``Static-Built-Using`` field must list source packages who's
+contents (like source code or data) were incorporated into the binary
+package during the build, including an "exactly equal" ("=") version
+relation on the version that was used to build that version of the
+incorporating binary package.
+
+Cases where this field may be used include (but are not limited to)
+linking against static libraries in other packages, builds for
+source-centered languages such as Go and Rust, usage of header-only
+C/C++ libraries and injecting data blobs into code.
+
+This is useful to track whether the package might need to be rebuilt
+when source packages listed here have been updated. This is important
+to stay ahead of the package failing to build from source (FTBFS) with
+the updated versions of the listed source packages, or security
+updates in the listed source packages.
+
+Unlike Built-Using, the Debian archive will **not** retain the
+versions of the source packages listed in the Static-Built-Using
+field. This means that any package listed in Static-Built-Using who's
+license requires its source code to be available must also
+simultaneously be listed in the Built-Using field.
+
+A package that needs domain name suffix data from the publicsuffix
+binary package would list it in the ``Static-Built-Using`` field like
+so:
+
+::
+
+ Static-Built-Using: publicsuffix (= 20231001.0357-0.1)
+
+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 the libraries contained in the
+librust-gtk4-dev and librust-pulsectl-rs-dev binary packages, where
+the latter is licensed under GPL-3+ (a license that requires full
+source code to be available), would have these fields in its control
+file:
+
+::
+
+ Built-Using: rust-pulsectl-rs (= 0.3.2-1+b1)
+ Static-Built-Using: rust-gtk4 (= 0.7.3-3), rust-pulsectl-rs (= 0.3.2-1+b1)
+
.. [#]
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