On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote:
Or in other words: packaging metadata are sources too. If they
change
(and a version bump constitutes a change) the output might change,
and
that's expected. What's key really is that the only things that can
effect generated output are the build/packaging environment and the
sources, but not parameters outside of that, such as the actual
wallclock.
The main way that packaging "interferes" with the source is when
patches are applied - the original timestamp of a tarball (for example)
isn't complete enough to use for $SOURCE_DATE_EPOCH. That's fair.
> My concern centers around the Copy on Write (CoW) use case - when
> packages are updated, some files changes, and some may stay the
> same.
> Where they are the same, we can save I/O and possibly download time
> long term.
Reproducible builds the way they are defined do not address such
file-level CoW optimization so much. They do address CoW optimization
on a package level much more however: i.e. the same package build
will
have the same files in them, no matter what.
Or to say this differently: if you want reproducible to work the way
ou think it should work, you'd have to start by convincing the
uptream
maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good
luck with that.
I think we should be careful to de-couple these two things. Just
because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not
proof that all binaries will. I remain concerned that this proposal
forces the issue and for every single version of every single ELF
binary *must* be different, even if they really didn't change. The
pattern I see is more automation and faster, smaller release cycles,
and this forcing downloads and writes of binaries that really didn't
change their code.
I have just thought of an alternative proposition: for ELF objects (and
ELF objects only): rpm could automatically, and systematically record
the metadata in an xattr. This would work on images without rpmdb,
works on most filesystem types, be serialized in archives. Most
interestingly this could be implemented as an rpm plugin, and would
work retroactively for packages that were built before this proposal.
It could also be made to work for other packaging systems, and the
tooling that reads it wouldn't need to know the original packaging
system.
Thoughts?
Matthew