My take on this is that lintian is getting the check wrong. Files that are changed as the result of a patch to a file that is processed during the build should be ignored - e.g. patching configure.in|ac should mean that changes in ./configure must be ignored. Why should a patch system try (and necessarily fail) to patch ./configure only to (fail to) implement the very change that patching configure.in|ac and running autoreconf achieves cleanly? (The patch will fail because ./configure changes frequently due to autotools updates when configure.in|ac does not.) --maintainer-mode is already dead, why should I need to return to the days of patching the same change twice?
In practise, this undermines the entire check because it is not going to
be easy for lintian to identify which files contain generated changes on
a reliable basis.
"this check is
designed to look for (basically, editing the package without being aware
that there's an existing patch system)."
In which case, I fear, the check appears to be over-simplified and I
don't see a reliable method for doing what the check is designed to do
without causing false positives like libgpewidget.
" If a patch created a file and
that file was also shipped in the diff, you end up putting the patch
system in an inconsistent state."
That is a case of trying to patch the same file twice - what we need to
avoid is the check for that problem causing maintainers to patch the
same *change* twice in more than one file when changing only one file
will generate the necessary changes in the second file during an
entirely normal build and without any other intervention.
These files are not being "patched twice" or "patched and changed
again", they are being changed by the effect of a patch on another file
causing a change in output from build tools. To fix that problem, we'd
need a radically different autotools design that strips out large parts
of the _orig.tar.gz and only packages the files that upstream actually
change (Makefile.am and configure.in) not the files that upstream
generate (Makefile.in and ./configure). Even that would be all well and
good for new or developing projects but unachievable on older projects
(like libjpeg6b) that haven't actually updated the build system for some
time. (That model is closer to the RCS model of upstream source -
generate everything everytime.)
If a patch modifies a file that is regenerated during the build using
data contributed from an external tool (like intltool, gettext,
autotools, gtk-doc, docbook, xsltproc, ....) then this patch is actually
far more likely to fail and may even fail simply when trying to rebuild
the package twice in a row. (The patch could not be unapplied cleanly
because the patched file has been changed by the build process.)
Simple example: If a package uses xsltproc to update a manpage from XML
but the package also contains the upstream manpage in order to make
generating the manpage optional for some builds, what is the point of
patching the manpage *and* the XML? Only the XML needs to be patched -
patching the manpage itself simply means that as soon as docbook-xsl is
updated to fix some bug in manpage output, my package becomes RC buggy
because the patch fails to apply - a patch that wasn't actually needed
in the first place. Does the maintainer now need to repackage the
_orig.tar.gz to remove the upstream manpage in order to patch it?
This whole thing was bad enough with --maintainer-mode causing patches
to ./configure and configure.in. (I've still got a few packages with
that problem - hopefully upstream will get it right for the next
release.)
These "patching-a-generated-file" bugs are *more* of a problem because
they cause a FTBFS due to the update of some third party package
(typically when the maintainer is busy with something else or away on
hols). If the generated file is not patched, the patch cannot fail - as
long as the effect of the patch is achieved through a patch to the
"source" file, the package will continue to build when other packages
change.
I found this lintian warning to be a problem with the libgpewidget
package - I cannot patch the changes to the doc/tmpl files because those
changes depend on how gtk-doc processes the doc/tmpl/ files in the first
place. Now it may well be that upstream could do with updating the
doc/tmpl files in the next release, but if there is nothing I can do
about it in the Debian package, why should I need a lintian override?
> > Would you agree to this? Is it possible to exclude created files from
> > this warning? I would further vote for excluding
> > changes.{sub,guess,rpath} and maybe even Makefiles and/or configure
> > scripts from this test. However, this is hust an optional suggestion.
>
> I personally think such changes should be made by running the relevant
> Autotools at build time, but I realize this is an ongoing debate and
> that's far from the consensus at the moment. I think we're still trying
> to feel out what Lintian's role should be here. I'd welcome any feedback
> from other people reading the mailing list.
If there is no consensus on changes to files like ./configure,
Makefile.in (when Makefile.am is patched), why has lintian gone ahead
anyway?
I think the check should only seek to find changes to *files that are
already patched* from also appearing in the .diff.gz - skipping any
files in the .diff.gz that are not listed in the patch set. It is these
"patch-and-change-same-file" bugs that will corrupt the patch process,
not the other changes that affect unrelated (and typically generated)
files.
IMHO it is a bad idea to try to patch a file that is modified during the
build process - wherever possible, patches should be against files that
upstream would normally edit to implement the desired change, not the
files that the build tools generate from those changes. Lintian should
not inadvertently undermine that principle.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
