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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131002001706.ga9...@virgil.dodds.net
