XPost: linux.debian.policy
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-devel@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)