Timo Röhling wrote:
> >> By default, CMake adds an RPATH entry to ELF binaries and deletes it
> >> again at install time. However, due to the limitations of some
> >> platforms, CMake will actually zero out the RPATH entry in the binary,
> >> leaking the original path length and thus making the build not
> >> reproducible (see the attached diffoscope output for an example).
> >>
> >> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
> >> since most package won't ever ship with an RPATH entry anyway, I propose
> >> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
> > Thanks for the suggestion.
> >
> > Has this proposal been tested on an archive-wide rebuild test to see how
> > much breaks with this option set?
>
> I don't know, but I don't think so. I'm not directly involved with the
> Reproducible Builds Team, I just pinged them on IRC after I filed this
> bug. Cc'ing them now.
As Vagrant implies we have not done an archive-wide rebuild test on
this specifically. (I was actually not aware of this specific issue
until now.) However, let me give you my general thoughts on using our
testing framework for staging changes.
Although we do have the ability to make changes to our toolchain to
test things we don't really like to do this unless absolutely
necessary. Every deviation from Debian itself is a "bug" of sorts and
only confuses users, developers and even the Reproducible Builds team
themselves when things are (for example) reproducible in one
environment or fail to build in a place that folks have zero control
or visibility over.
In addition, in the past when we have had temporary changes they have
persisted far longer than anyone planned. This leads to frustration
and highly-demotivating outcomes when maintainers no long feel a
pressing need to accommodate a change because "well, all the packages
are now reproducible". Well, yeah, I *guess* …
Lastly, making just a small change is actually non-trivial to do and
involves more technical and cognitive overhead than it sounds. "Just"
is a dangerous word, as I am sure you all know. This could probably be
fixed, but we have limited bandwidth and we aren't trying to be a
staging ground anyway. I suppose this would be mitigated if we only
needed to export that particular Debhelper environment variable from
our 'master' build environment vs. uploading a patched package, but
the above arguments still stand as a general rule.
In other words, unless you have no reason to suspect that lots and
lots of things will break, I would highly and strongly recommend that
you simply make the changes in CMake/debhelper and upload. :)
(Speaking only as myself, I don't represent the entire Reproducible
Builds project, etc. etc. etc. And I am partly writing this so I can
refer others to it later in other parallel contexts...)
Thanks for working on this. :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
