Two questions about build-path reproducibility in Debian

[Vagrant Cascadian]

On 2024-03-05, John Neffenger wrote:
> On 3/5/24 2:11 PM, Vagrant Cascadian wrote:
>>> I have no way to change these choices.
>> 
>> Then clearly you have not been provided sufficient information,
>> configuration, software, etc. in order to reproduce the build!
>
> Rather, I really can't change it or configure it any differently.
>
> Three builds:
>
> (1) A build on Launchpad submitted from their webpage uses this path:
>
>    /build/openjfx/parts/jfx/build/
>
> (2) A remote build on Launchpad submitted locally with this command:
>
>    $ snapcraft remote-build
>
> uses this path:
>
>  
> /build/snapcraft-openjfx-64b793849f913c7228cd17db40a05187/parts/jfx/build/
>
> (3) And a build run entirely local with this command:
>
>    $ snapcraft
>
> uses this path:
>
>    /root/parts/jfx/build/
>
> What am I to do?

Well, to state the obvious in this case, yes, you either need to fix
your tooling to support some mechanism to provide a consistent build
path, switch to different tooling that already supports a consistent
build path, or fix this particular software to build reproducibly
regardless of build paths.

Each approach has different advantages and disadvantages.


>> That was a fundamentally different issue about having builds not produce
>> bit-for-bit identical results still meeting some sort of reproducible
>> criterion, as opposed to this discussion is, as I see it, about
>> normalizing the path in which the build is performed in order to get
>> bit-for-bit identical results.
>
> I understand and recognize the difference you highlight between this 
> discussion and the previous one. Yet I would hesitate to call it 
> fundamental for the reasons below.
>
> The main reason people didn't want to relax any requirements back in 
> October 2022 is because then the pressure is off -- it removes our 
> leverage. If you lower our standards, we may never get the upstream 
> projects to the goal we really want: fully reproducible builds 
> independent of these random differences.

I guess we differ on the "main reason" ... both of us having
participated in that discussion. :)

I agree that higher standards are in general better, but I am more
concerned with the outcome than this particular issue regarding build
paths.

That said, I am very glad to hear there are projects actively working on
fixing build path issues!

I argued time and time again in favor of continuing to test build paths
in Debian, largely because some commonly used debian tooling still
varies build paths out of the box, I have filed dozens of build path
related bugs and marked hundreds of packages affected by build paths,
pushed for related changes in core packaging tooling in Debian
(e.g. dpkg, debhelper) to fix build paths issues... but I also see the
pragmatic reasons why it is tolerable, if not ideal, to just use
consistent build paths.


> It has sometimes taken me years(!) to get a single reproducible builds 
> pull request accepted.

Likewise. Which...

> If they find out they can be "reproducible" without some of these
> bothersome changes, it just makes my job that much more difficult.

... is why some people might want to prioritize which issues they want
to spend their time on. We always have to pick our battles, and allow
others to pick their battles.

That means that we do not always support each other in all things, but
we can support each other in most things, and that seems more important
to me, at least in this case.


> I'll make the same argument I made over a year ago:
>
> Reproducible builds is about /blasting/ away all the useless, 
> meaningless differences: the timestamps of files created during the 
> build, the unsorted order of files in their directories, or the random 
> build paths used in a transient container. When the useless differences 
> are removed, the meaningful differences can be found.

That is certainly one angle on it, and a good one!

Yet, the Reproducible Builds Definition is more flexible. It gives room
for individual projects to focus on their own priorities, while
requiring sticking to bit-for-bit reproducibility. 


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20240306/9f80d0e6/attachment.sig>