Re: [debian-devel] 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 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.
From the social contract (uppercasing is mine):
"To support these goals, we will provide an integrated system of
HIGH-QUALITY, 100% free software"
> > > 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
Well, let's see the definition of source.
From the GPL:
"The source code for a work means the preferred form of the work for
making modifications to it."
The term "the preferred" and engineering practices imply that
there is _one_ source, and anything which is generated from it
is not source.
I remember seeing a lengthy explanation of this from either
RMS or ESR, but cannot provide a pointer to it.
The "sourceness" of a file does not depend on where it is included.
> 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.
It does matter. If upstream used a tool to generate the
files and continues to do so, then they are not the preferred form
of modification, hence not the source.
If the source is not included in the upstream "source archive", then it is
not an open source software, hence it should not be included Debian.
If the upstream uses some non-free tools which cannot be included in
Debian, then the package should not be included in Debian
because it depends on proprietary software which is prohibited by the
Social Contract.
If the upstream uses some tools which is not included in Debian,
then it also cannot be included in Debian because dependency reasons,
even if the tools are open source.
>
> This (weird 3rd party tools) is not the case, and upstream provides even
> their command-line options which they used to generate those
> sourcefiles.
Happily.
>
> > > > 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.
I don't think that disagreeing with well-known facts helps.
> 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]
The build system does support defining the exact version of automake
to be used, and even declaring which packages should not be in system
in build time. This is Build-Depends: and Build-Conflicts:
Hence your argument does not stand.
--
GNU GPL: csak tiszta forrásból
Reply to: