[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [debian-devel] Re: [debian-devel] Hidden timeskew problems might show up on 2.6.x kernels



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.

> 2) is unreproducable to other people unless they know which
> automake/autoconf etc I used

Build-depends helps you with this.

> 
> > -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.

> 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.

-- 
GNU GPL: csak tiszta forrásból



Reply to: