Re: Rebuilds with unexpected timestamps [and 1 more messages]
On Mon, Oct 31, 2016 at 01:42:26AM +0000, Ian Jackson wrote:
>...
> Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"):
> > Be prepared to see a lot of such issues when you touch random files.
>
> I'm certainly expecting to see lots of issues.
>
> IMO if a package FTBFS when its timestamps are permuted, that is
> probably an RC bug. It means that there are some files in the
> package, which it thinks it needs as part of the build process, but
> which cannot actually be built.
>
> 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.
> > If you want this to work properly, Debian has to move from using the
> > generated release tarballs to the actual source in the upstream VCS.
>
> If the upstream tarballs are sufficient and our clean target ensures
> that everything is built from source, it can still work.
It can be made to work.
But I do not think it makes sense to do it this way.
Release tarballs contain sources plus generated files.
Lets look at the common "upstream uses git and autotools" case:
Using release tarballs made sense back in the days when git did not
exist and Debian used the generated files for
./configure && make && make install
This already changed when packages started to use autoreconf on
a larger scale.
What you will end up with in practice is basically removing all
generated files in the clean target.
This means that packages will use the release tarballs,
and then remove all files that are not in git.
At that point the best solution would be an alternative source package
format that is based on git.
The much-used git-buildpackage is already in that direction, and hacks
like pristine-tar would disappear with an alternative source package
format.
> 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: