On Wed, Apr 14, 2021 at 11:30 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>
> On Tue, Apr 13, 2021 at 12:44:42AM +0000, Matthew Almond via devel wrote:
> > 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.
>
> Yeah, that's definitely something to think about.
>
> The proposed change indeed "forces the issue". This could be a big
drawback
> or not, depending on how often identical binary builds happen for different
> package versions. If it turns out that the answer is "only rarely", then
> I wouldn't consider it too important. If the answer is "quite often",
we
> would a chance for a nice optimization.
>
> I wanted to investigate this, but unfortunately, it's hard to check
> right now, because all builds are non-reproducible (in the sense of
>
reproducible-builds.org), because we include the mtime of build
> products in rpm metadata, so pretty much all binary rpms are
> different. And in general other things make builds non-reproducible,
> and it's not obvious if *this* change makes things worse. I didn't
> want to dig into individual rpms to compare binaries. I *think* most
> packages are not actually rebuilt that often without changes…, but real
> data is definitely needed.
>
We could start clamping times by default by adding the following to
redhat-rpm-config:
%clamp_mtime_to_source_date_epoch 1