Maytham Alsudany <maytha8thedev@gmail.com> writes: > 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! 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. 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'? /Simon
Attachment:
signature.asc
Description: PGP signature