Re: Bug#688251: #688251: Built-Using description too aggressive

[Steve Langasek <vorlon@debian.org>]

On Sat, Sep 28, 2013 at 03:01:51PM +0200, Stefano Zacchiroli wrote:
> On Mon, Sep 23, 2013 at 09:08:55AM -0700, Russ Allbery wrote:
> > The question is how to make it clear that's not the intent, which
> > requires figuring out how to separate the other use cases from the gcc
> > and glibc case.

> I guess the general answer you're looking for depends on the use cases
> Built-Using wants to address (is it licensing? is it code embedding to
> help the security team? is it just metadata to note what has been built
> against what?). I confess that the answer to this preliminary question
> is not clear to me (anymore).

By definition, the answer is "those cases where we want to make sure the
built-using packages match the binaries at release time" - i.e., if we would
want to rebuild the package before release when the package it build-depends
on has revved, and this information isn't already captured in e.g. a
strict versioned binary dependency, we should use built-using.

So we do care about this for cases where the licensing requires us to keep
them in sync, and in that case it should be a hard, fast rule.  We shouldn't
care about it for cases like libgcc, where the embedded code has a licensing
exception; or for autotools, where the code in the archive may change
frequently, but the contribution of these tools to the code output in the
binary packages as part of the build is negligible and should not change
significantly over time.  But for, say, signed EFI bootloaders that require
two round-trips to the archive in order to get the signed binaries into a
package, or for packages which embed static libraries that are GPLed, I
think we should care about it.  And for the installer, which embeds a LOT of
other binary packages in its output, we should care about it.

I think this was broadly understood when Built-Using was crafted.  The
challenge is to distill that into policy-appropriate guidance.

> > I suppose one possible approach is to just explicitly exclude the C
> > library and compiler from the current wording.  (Although I'm not sure
> > that should be the case for every compiler; for example, do some of
> > the more complex compilers for languages like Haskell actually need
> > Built-Using?)

> I'm no Haskell expert, but AFAIR the language behave very similarly to
> OCaml in this respect.  OCaml does static linking (of native OCaml code,
> not necessarily of external C libraries) by default, so, at the very
> minimum, you have code embedding in all executables. For OCaml you might
> also have code inlining between libraries; I'm not sure if that's the
> case also for Haskell or not.

> Now, does that mean that you need to add OCaml/Haskell software to the
> list of exceptions? I'm not sure, it really depends on the intended
> Built-Using use cases.

The root question is, what do we expect to see happen to these stacks at
release time?  Do we expect that the OCaml and Haskell stacks get rebuilt
before release, to ensure that the binaries we ship correspond to the full
actual source?  I'm not sure whether we want to do that, but I do consider
it a bug for these languages to not support dynamic linking.  And if we
think that Haskell and OCaml packages shouldn't need to use Built-Using to
track their static linkage, I believe that needs to follow from general
principles, and not be an exception granted to them because too many
packages would be affected.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org