@pmatilai converted this issue into discussion #2934.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2894#event-11947622981
You are receiving this because you are subscribed to this thread.
Message ID:
> As @Conan-Kudo mentioned above, we have to strip metadata _anyway_. At least
> `HEADERIMMUTABLE`, `SIGSIZE`,
> `SIGMD5`, `SHA1HEADER`, `SHA256HEADER` are "irreproducible"
Wait, what? If those differ then the packages do differ, so its not actually
bit-per-bit identical. Which is what *I've*
> a coherent (re)design for reproducible builds, where you basically just flick
> it on and be done with it
I agree that the current set of options is a bit ad-hoc. But I think it's
completely unrealistic to achieve a single switch, because different build
systems and ways of managing the
As long as a constant buildtime value is provided, it will also result in
constant (reproducible) mtime.
Reproducible builds requires that you can produce bit-identical output from
identical inputs. And inputs would include buildtime here (or whatever it is
based on, e.g. changelog date).
--
Clamping the mtime to buildtime has its own negative consequence too, because
it makes it harder to reason reproducibility and it invalidates reproducibility
in practice because every build will be different due to a variable clamp
rather than an immutable clamp.
--
Reply to this email
One of the reasons for the knobs is that not all of these settings are fully
useful for "reproducibility" and some of these harm traceability and debugging.
For example, forcing the build host to `reproducible` does not provide much
value if you are able to do comparisons while
I wont claim to have digested all that, but just a high level confirmation:
what I really would like to see is a coherent (re)design for reproducible
builds, where you basically just flick it on and be done with it, whereas the
existing flags reflect the organic growth process over the years
I think @pmatilai meant having %source_buildtime with constants of either
`SOURCE_DATE_EPOCH`, `SOURCE_DATE_EPOCH_MTIME`, `macro` or `clock`? I'm ok with
that.
My preferred way would be as few macros or settings, but that is not as
backwards compatible. Only reproducible builds. Build host
We have open-build-service (OBS) that uses obs-worker to call obs-build to call
rpmbuild.
The current way documented in [our
wiki](https://en.opensuse.org/openSUSE:Reproducible_Builds) is to add a
project-conf in OBS
```
Macros:
%source_date_epoch_from_changelog 1
> With our build system, passing constants into a build is much easier than
> passing in a variable %_buildtime.
Sorry but I have no idea this means. What are these "constants" and how are
they being passed to a build?
(a %_buildtime macro could be set either via rpmbuild command line --define
> %clamp_mtime_to_buildtime seems sensible to me, at least if it replaces
> %clamp_mtime_to_source_date_epoch. If you care about source_date_epoch, then
> you'll surely set buildtime to it, right?
With our build system, passing constants into a build is much easier than
passing in a variable
Forward-looking defaults aside...
Do you agree with the idea that there should be a single macro to set the
buildtime source (clock/macro/source_date_epoch), and then have a separate flag
for clamping mtimes to buildtime, or am I again missing some finer detail here?
I've nothing against
In other words, this all would make a whole lot more sense to me if there was a
switch that decides where the buildtime gets set from
(clock/macro/source_date_epoch), and then the clamping options relate to
*buildtime* and not source_date_epoch. @ffesti mentioned elsewhere that maybe,
instead
We have `%_buildhost` macro which seems like it should be paired with
`%_buildtime` so adding that seems to make sense, but I guess the latter is
missing because you can set it with SOURCE_DATE_EPOCH if you care. I'd totally
fine with adding `%_buildtime` override if that means tossing the
14 matches
Mail list logo
