Re: [debian-devel] Re: [debian-devel] Hidden timeskew problems might show up on 2.6.x kernels
On Tue, Jan 13, 2004 at 10:46:11PM +0000, Magos?nyi ?rp?d wrote:
> A levelez?m azt hiszi, hogy Jeroen van Wolffelaar a k?vetkez?eket ?rta:
> > On Tue, Jan 13, 2004 at 09:59:10PM +0000, Magos?nyi ?rp?d wrote:
>
> > I deliberately did not rerun automake, because
> > 1) this might introduce new problems
>
> Cannot parse this. Compiling the package can also introduce
> new problems, just like getting up at the morning.
> Experience has shown that failing to rerun automake
> did introduce a new problem.
AFAICS, you do parse it, but disagree about the imporance of this
reason. I do stand by it.
> > 2) is unreproducable to other people unless they know which
> > automake/autoconf etc I used
>
> Build-depends helps you with this.
There was a thread _very_ recently on -devel about wether to
autoconf&automake at packaging time or at build time, and as far as I
remember, the conclusion was that it would cause less surprises if
it were to happen at packaging time. This introduces however the problem
of different autotools versions, which I circumvented altogether this
way.
> > > -You are in trouble if the outcome of the build depends on the
> > > relative mtime of any combination of source files.
> >
> > Because of my previous point, I did manually patch *both* Makefile.am
> > and Makefile.in, consistently with eachother (it was a simple literal
> > string replace, so it was easy to manually induce how .in would be
> > changed based on my .am changes. I could also have run automake again,
> > with the correct version, and I suppose that would have been okay too.
> > Again, the correct automake version is not recorded in build-depends, so
> > will need to be manually checked if you choose to regenerate the
> > Makefile.in
>
> Well, this is a bit lengthy explanation of what kind of trouble you are
> in.
>
> > > -Makefile.in was not a source file in your case. It should have
> > > been deleted by debian/rules clean.
> >
> > It was, both Makefile.in and Makefile.am were in upstream. See further above.
>
> No. By definition, generated files are not source code.
> It does not matter if the upstream provided them or not.
> Makefile.in is provided for convenience of those unlucky who should
> go into too great length installing automake et al in their machines.
> This is not the case in Debian.
I disagree. You never know what kind of special things upstream has done
to their generated files, what extra macro's they had installed, etc
etc. By simply keeping your hands off files you do not need to touch, or
in this case, by painting the dirty spot of your Van Gogh over rather
than repainting the whole painting based on the original sunflower,
there will be no visible consequences if your pencils and paint are of
inferior quality, or your painting skills are inferior, and you don't
even have to bother what pencil and paint Van Gogh used while making his
painting.
> > And, it remains true that without dpkg-source passing the -Z flag to
> > patch, build success could depend on your kernel due to timestamp
> > problems, and that the order in the .diff does matter in regard to
> > whether some (unspecified!) version of automake will be invoked on
> > build.
>
> But it is a bug in the package source, not in the toolchain.
> So it should be corrected there.
You can have a correct package source, but generating the .diff.gz by
means of dpkg-source and then again unpacking it by means of the same
tool, has currently the property that if originally A was newer than B,
this might now have been reversed.
By adding -Z to patch on dpkg-source -x time, mtimes are preserved,
my educated guess is that there is no big impact (the mtime's at
packaging time must have worked otherwise the maintainer's build would
have failed). Only one extremely slight caveat: on 2.6, if A newer than
B, but mtime in same second, A will have equal mtime to B at unpack
time. This is however not fixeable, and I really doubt this will cause a
bug, as make takes same mtime as 'no need to rebuild'.
--Jeroen
--
Jeroen van Wolffelaar
+31-30-253 4499
Jeroen@A-Eskwadraat.nl
http://Jeroen.A-Eskwadraat.nl
Reply to: