[Reproducible-builds] Building packages in the *past* (!!)

[Johannes Schauer]

Hi,

Quoting Chris Lamb (2015-09-30 11:57:20)
> > There is a minimum of sanity that we should assume on the autobuilders,
> 
> Agree in principle..
> 
> > namely, that packages are built on a date which is later than the one
> > in the last changelog entry.
> 
> .. but why should this matter? In fact, there's a fairly strong argument to
> be made

I'd like to hear that "strong argument" because I fail to come up with one.

> that if the package does something weird in this case then there's something
> far deeper wrong or broken with it - and therefore it would be advantageous
> to know about it simply from a QA point of view.

I would not find it unreasonable if a build would fail if some of the software
that is run either during compilation or testing stages detects that some of
the files they are working on have a timestamp from the future. So the
questions are:

 - do you want to file bugs against software that cannot work with timestamps
   from the future?

 - Why is it a bug if software cannot work with timestamps from the future?

 - What is the real world problem that is fixed by this?

 - Is there a use case where you would like to build your software with your
   clock set back to an older timestamp?

 - Having the complexities of timezones in mind I can totally imagine that
   there exists bugs that let your package not be built at a certain point in
   the past but I do not see how *all* software that cannot be built in the
   past will also have a general QA problem which has to be fixed in the
   future. Thus, if you build in the past you might also end up with build
   failures that are not meaningful.

 - Which QA scenario do you have in mind which would not also be checked when
   building in the future instead?

Personally, I find it very likely that there exists software that cannot handle
timestamps from the future because for that software it could easily hint that
something in the runtime environment is obviously wrong and has to be fixed.

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150930/402591a2/attachment.sig>