Re: Rebuilds with unexpected timestamps [and 1 more messages]
On Mon, Oct 31, 2016 at 03:58:12PM +0000, Ian Jackson wrote:
> 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.
What I am trying to say is that you will be opening a huge amount
of bugs for a very exotic problem, and that there is a solution
that will automatically fix a large part of them.
Many of the problems you are trying to solve would not be present if
Debian would not be using upstream release tarballs.
A new git source format and a gradual switch to that would be a clean
solution to solve most of these issues for a large part of the archive.
>...
> 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.)
I am talking about a source format where the sole contents of the
.orig.tar is the upstream .git, and the sole contents of .debian.tar
is debian/.git
> Ian.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: