Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more
messages]"):
> On Mon, Oct 31, 2016 at 01:42:26AM +0000, Ian Jackson wrote:
...
> > If it does "sufficiently different" things, but still succeeds, when
> > the timestamps are permited then that's probably a minor or normal
> > bug: evidently it can build either way, but this kind of situation is
> > probably not intentional and it is setting us up for a future latent
> > FTBFS.
>
> The case where I end up with a building but broken "hello" program
> worries me a lot more than the case where I get a FTBFS in hello.
>
> "hello has an empty version number" sounds harmless, but in a lot of
> cases the program or other packages using it might actually parse the
> version number.
>
> And I'd guess you might end up with even more complicated runtime issues
> if you mess with the timestamps of random files.
I'm confused by what your point is. Are you saying that issues of the
category I quote myself describing, above, should be considered RC ?
I think the archive probably has a great many situations of that kind,
and that my proposed approach to detecting them may not survive
contact with reality.
If you are as worried as you say about this, then I look forward to
your help in trying to do rebuilds with timestamp-fiddling and trying
to analyise the copious piles of indigestible build logs which I
expect such a process to produce.
Personally given my view that such bugs are probably not too serious,
I was intending (when I get round to it, which may not be soon) to
take crude measures to try to keep the false positive rate down.
> This means that packages will use the release tarballs,
> and then remove all files that are not in git.
This could be easily achieved by a combination of dgit and my proposed
`3.0 (rsync)' source package format. If you're concerned about this
aspect, perhaps you would care to help with `3.0 (rsync)' ? I sent a
Request For Help here but sadly no-one stepped up.
If you are interested in that, it might be best if (unpopular as I
sometimes make myself) I fronted the proposals to the various
stakeholders. But I could sure use help with (eg) support in dak, and
finishing off support in dpkg-source.
> At that point the best solution would be an alternative source package
> format that is based on git.
I think dgit is a part of this jigsaw. It allows maintainers using
git to publish a canonically-useful git history in a canonical
location.
I think dgit plus the hypothetical `3.0 (rsync)' has all the
properties you would hope for. (There would still have to be .origs;
it's up to each maintainer whether those would be upstream's, or made
by gbp calling git-archive, or whatever.)
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
