Hi all, I would greatly appreciate it if you could have a look at the proposal attached below to add a new section to the Debian Policy detailing the use of the Static- Built-Using and differentiating it from the Built-Using field.
Could you please ensure that it aligns with your goals in the Golang/Rust teams and that it matches your expectations? If there is anything that is surprising to you or something that doesn't make sense please let me know. Otherwise, I encourage you to send a signed statement endorsing the patch as-is. The bug log and full patch file can be found at https://bugs.debian.org/1069256 (Note that the patch has been revised, the patch attached to the first message is not the one currently being proposed.) Thanks, Maytham PS: I'm around on IRC in #debian-(rust|golang|devel) if you want to discuss. On Sat, 2024-04-27 at 17:40 +0800, Maytham Alsudany wrote: > 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. [..] > 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 >
signature.asc
Description: This is a digitally signed message part
