Re: [debian-devel] Re: [debian-devel] Hidden timeskew problems might show up on 2.6.x kernels
On Tue, Jan 13, 2004 at 11:55:53PM +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 10:46:11PM +0000, Magos?nyi ?rp?d wrote:
> > > A levelez?m azt hiszi, hogy Jeroen van Wolffelaar a k?vetkez?eket ?rta:
> > >
> > > > I deliberately did not rerun automake, because
> > > > 1) this might introduce new problems
> > >
>
> It did took a time to figure it out.
> Rerunning automake do not introduce new bugs, merely
> turns out bugs hidden so far.
> I guess this is the main point we disagree on.
> I prefer bugs to be fixed while you prefer bugs not
> to pop out. In the short run you may see less bugs,
> but in the long run maybe my aproach is better.
I agree, provided that you take care to use exactly the same tools as
upstream (see ~20 lines below why this could be impossible). Then your
argumentation is right. Also, I would find more bugs earlier if I did a
full audit of upstream's source, while if I didn't, they would pop out
sooner or later. In the long and short run, that approach would be
better, quality-of-package-wise. It however takes significantly more
time to do.
I do not believe it is the task of Debian to pro-actively debug and
sanity-check upstream, as packagers, maintainers, I believe it is the
task of Debian to fix bugs when we encounter them and/or are they are
reported to us. Debian is no BSD.
> > 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.
>
> I would consider all of the above cases as bugs. The source should
> fully define the build process and the resulting program.
It happens that the generated files _are part of the source_. The only
difference is, that upstream used some 3rd party software package to
make and maintain those files, rather than write them by hand, but this
does not change the fact that they are part of the source. What if
upstream used an propriatary tool to generate those files? What if
upstream used some GPL'd tool we do not have? It doesn't matter, because
there is no good reason to (be able to) make the sourcefile again, as
long as we are able to modify it as is required by the DFSG.
This (weird 3rd party tools) is not the case, and upstream provides even
their command-line options which they used to generate those
sourcefiles.
> > > 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.
>
> The mtime of sources shall not be significant in the definition of build
> process, as mtime is only a way for make to figure out the causality of events.
> There should not be causality between source files, as a source file which
> is caused by another source file is not a source file because it is generated.
> QED.
As stated above, I disagree that a generated file is not a source file.
Also, the hypothesis (I'm not implying you made that hyposthesis) that
"mtime should not matter as in the worst case the generated file gets
regenerated and nothing is wrong" can be refuted as such:
This is a flaw in the build system: it does NOT completely and
unambigiously define how to generate B from A, because it merely states
`automake is the tool to generate B from A' rather than `the program
automake by GNU, version 1.4, as obtainable in .tar.gz with md5 of foo
from http://gnu.org/.../automake.tar.gz with this and this patch applied
is the tool to generate B from A'[1]
--Jeroen
[1] It would IMHO benefit the OSS community a lot if make were to
support at least part of it (defining versions of tools), so that
one can always reproduce that upstream did. That it is not the case
currently, means that rerunning those tools can be a tough exercise.
--
Jeroen van Wolffelaar
+31-30-253 4499
Jeroen@A-Eskwadraat.nl
http://Jeroen.A-Eskwadraat.nl
Reply to: