Hi! On Thu, 2024-04-18 at 23:29:11 +0300, Maytham Alsudany wrote: > Package: debian-policy > Version: 4.7.0.0 > Severity: normal > X-Debbugs-Cc: debian-de...@lists.debian.org
> 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[...])". I think this (and the policy proposal) is omitting several important parts for the intended use for the field, as it was considered on its addition. Quoting from deb-control(5) for context, which I think covers the concerns from the mails from Simon and Chris: Built-Using: <package-list> This dependency field lists extra source packages that were used during the build of this binary package, for license compliance purposes. This is an indication to the archive maintenance software that these extra source packages must be kept whilst this binary package is maintained. This field must be a comma-separated list of source package names with strict ‘=’ version relationships enclosed within parenthesis. Note that the archive maintenance software is likely to refuse to accept an upload which declares a Built-Using relationship which cannot be satisfied within the archive. Static-Built-Using: <package-list> This dependency field lists extra source packages that were used during the build of this binary package, for static building purposes (for example linking against static libraries, builds for source-centered languages such as Go or Rust, usage of header-only C/C++ libraries, injecting data blobs into code, etc.). This is useful to track whether this package might need to be rebuilt when source packages listed here have been updated, for example due to security updates. This field must be a comma-separated list of source package names with strict ‘=’ version relationships enclosed within parenthesis. Supported since dpkg 1.21.3. > 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. Thanks for starting this! As mentioned before I think the currently proposed description is too restrictive and specific to Go and Rust, and it should be expanded. 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.) Thanks, Guillem