Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1231575 > unrolled thread

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using Simon Josefsson <simon@josefsson.org> - 2025-02-03 13:40 +0100
    Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using Maytham Alsudany <maytham@debian.org> - 2025-03-02 06:30 +0100
    Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using Simon Josefsson <simon@josefsson.org> - 2025-03-03 12:10 +0100
      Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using Maytham Alsudany <maytham@debian.org> - 2025-03-15 03:30 +0100
        Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using Matthias Geiger <werdahias@riseup.net> - 2025-03-30 15:50 +0200

#1231575 — Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Multipart message — attachments visible in raw view] — view raw

Maytham Alsudany <maytha8thedev@gmail.com> writes:

> +``Static-Built-Using``
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +This ``Static-Built-Using`` field must list source packages with an
> +"exactly equal" ("=") version relation, which had their contents (like
> +source code or data) incorporated into the binary package during the
> +build.

I have a (possibly non-typical) situation that I believe warrant use of
Static-Built-Using and I find the above explanation ambiguous wrt if the
transitive closure of packages should be included or not.

(A side-note is that referring to source package names in
'Static-Built-Using' makes it hard to know which binary package from
that source package actually ship the embedded code.  I suspect it is
too late to change this though.)

My naive reading of the text above suggests that ALL source packages
with that property ought to be included.  I'm not certain that is a good
idea or even if this is intended.

My situation is that 'tkey-ssh-agent' embeds a RISCV firmware app blob
which comes from the 'tillitis-tkey-device-signer' package which embeds
RISCV object code from the 'tillitis-tkey-libs' package.

In an upcoming upload, I plan to add

Static-Built-Using: tillitis-tkey-libs (= 0.1.2-2)

to the 'tillitis-tkey-device-signer' package.

However, what is the right header for the 'tkey-ssh-agent' package?
Naively interpreted, I think the above policy would suggest this:

Static-Built-Using: tillitis-tkey-libs (= 0.1.2-2), tillitis-tkey-device-signer (= 0.1.2-2)

However is that useful?  Wouldn't the following be sufficient:

Static-Built-Using: tillitis-tkey-device-signer (= 0.1.2-2)

Code that goes looking at the 'tillitis-tkey-device-signer' source
package ought to be able to find that one of its binary packages, namely
'tillitis-tkey-device-signer', has a Static-Built-Using on another
package.

The problem with interpreting the text above as indicating the
transitive closure is that there may be no end to the list.  For
example, 'tillitis-tkey-libs' most likely embeds static code coming from
the compiler, in the 'clang-19' package (or some other dependent package
of 'clang-19').  Should 'clang-19' be added to 'Static-Built-Using'?
Recursively, I suspect that the 'clang-19' binary package in Debian of
version X either embeds static code coming from gcc version Y or clang
version X-1.  Should 'clang-19' have a Static-Built-Using on its
compiler?  I'm not sure this is useful or intended.

Maybe adding an example for embedded static C object code like this
would help clarify the intention.

/Simon

[toc] | [next] | [standalone]

#1235704

[Multipart message — attachments visible in raw view] — view raw

Hi Simon,

On Mon, 2025-02-03 at 13:32 +0100, Simon Josefsson wrote:
[...]
> Maybe adding an example for embedded static C object code like this
> would help clarify the intention.

Would adding the following after the first paragraph be sufficient in 
your view?

  Note that you do not need to list source packages recursively. For example, 
  consider the following situation: A package named "foo" declares 
  Static-Built-Using on "bar". "bar" declares Static-Built-Using on "baz". As 
  long as "foo" does not directly incorporate the contents of the "baz" package 
  during its build, then "foo" must not list "baz" in its Static-Built-Using 
  field.

--
Maytham

[toc] | [prev] | [next] | [standalone]

#1235890

[Multipart message — attachments visible in raw view] — view raw

Maytham Alsudany <maytham@debian.org> writes:

> Hi Simon,
>
> On Mon, 2025-02-03 at 13:32 +0100, Simon Josefsson wrote:
> [...]
>> Maybe adding an example for embedded static C object code like this
>> would help clarify the intention.
>
> Would adding the following after the first paragraph be sufficient in 
> your view?
>
>   Note that you do not need to list source packages recursively. For example, 
>   consider the following situation: A package named "foo" declares 
>   Static-Built-Using on "bar". "bar" declares Static-Built-Using on "baz". As 
>   long as "foo" does not directly incorporate the contents of the "baz" package 
>   during its build, then "foo" must not list "baz" in its Static-Built-Using 
>   field.

That would be an improvement, thank you!

Thanks also for agreeing that this is the reasonable interpretation for
this situation, I wasn't 100% certain on that.

I believe the phrase

   "does not directly incorporate the contents"

still leaves room for ambiguity though.  Certaintly to some way of
reading "foo" WILL incorporate the particular bits coming from "baz"
directly, since those bits are provided identically within the "bar"
package.

Can we find some better articulation of the concept?

If package "bar" has "Static-Built-Using: baz", and could even have a
"Depends: baz" so that "baz" is actually installed when "bar" is
installed, I believe what we want is that a package "foo" that
Build-Depends on "bar" and statically uses files from "bar" to have
"Static-Build-Using: bar" when it refers ONLY to files in "bar".  If
"foo" also refers to and uses files provided by "baz" then it MUST also
have "Static-Build-Using: bar, baz".

I think the property we care about for distinguishing the recursive case
is more about the exposed interface (normally filenames) rather than the
actual content of the files.  The content WILL be included recursively,
that's the point of statically linking.  But mirroring that in
Static-Built-Using is not useful, as it will chain back to include all
compiler versions used to build them (and potentially the compilers that
built those, etc).  So we only mirror the filename interfaces needed.

I hope someone else can find better terminology and description of the
desired behaviour.

I'm also find with using your improved explanation as-is, and leave my
comment describing this detail in the bug tracker for future word
tweaks, in case there is ever any real problem due to this ambiguity.

/Simon

[toc] | [prev] | [next] | [standalone]

#1237818

[Multipart message — attachments visible in raw view] — view raw

Hi Simon,

On Mon, 2025-03-03 at 11:58 +0100, Simon Josefsson wrote:
> I believe the phrase
> 
>    "does not directly incorporate the contents"
> 
> still leaves room for ambiguity though.  Certaintly to some way of
> reading "foo" WILL incorporate the particular bits coming from "baz"
> directly, since those bits are provided identically within the "bar"
> package.
> 
> Can we find some better articulation of the concept?

Perhaps a footnote on what "directly incorporating" means?

  Note that you do not need to list source packages recursively. For example,
  consider the following situation: A package named "foo" declares
  Static-Built-Using on "bar". "bar" declares Static-Built-Using on "baz". As
  long as "foo" does not directly incorporate the contents [#]_ of the "baz"
  package during its build, then "foo" must not list "baz" in its
  Static-Built-Using field.

  [...]

  .. [#]
     A good indication is whether "baz" needs to be listed the Build-Depends of
     "foo". In other words, if upstream's buildsystem in "foo" explicitly looks
     for "baz" or its source code imports something provided by the "baz", then
     "baz" should be listed in the Static-Built-Using field of "foo".

--
Maytham

[toc] | [prev] | [next] | [standalone]

#1239860

On Sat, 15 Mar 2025 10:25:27 +0800 Maytham Alsudany <maytham@debian.org> 
wrote:
>[...]
Hi Maytham,
thanks for your work.
Consider this seconded by me, too.

best,

werdahias

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web