Re: [RFC] Go (golang) packaging
* Michael Stapelberg:
> Florian Weimer <fw@deneb.enyo.de> writes:
>> My main worry is that, for example, a fix in another, otherwise
>> unrelated dependency prompts a rebuild, and this picks up behavioral
>> changes which haven't been visible before, but lingering in the static
>> library. Essentially, we end up with non-reproducible builds.
> Could you provide an example please? I don’t understand how this is
> different with static linking than with dynamic linking yet.
With dynamic linking, you pick up the behavior change along with
"apt-get upgrade", so I expect that we get much more testing of the
combination during development.
Technically, you are correct that we generally do not do purely static
linking—preprocessor macros can change, and so can the value of enum
constants. And with C++, there are many, many more language features
which escape dynamic linking. But I think the lingering change
phenomenon is still a valid concern with static linking.
(One approach which doesn't seem to have been discussed so far is
compile-on-installation, à la common-lisp-controller. Not sure if
this is a good idea. Linking-on-installation does not appear to be
sufficient.)
Reply to: