Re: Generated changes and patch systems
Neil Williams <codehelp@debian.org> writes:
> On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote:
>> Uh, it's the same problem. Surely the generalization is obvious?
> It's not quite the same problem because aclocal.m4 is regenerated in the
> clean rule itself because changing it causes ./configure --recheck to
> recreate the (modified) file. So instead of copying it around, it has
> to be deleted - merely because a patch system is in use. Seems crazy to
> me.
Yes, deleting it is what I've been trying to tell you to do from the
start. :) Moving it around is generally a waste of time. The examples
that I've been pointing you to just delete such files.
And no, lintian only happens to *detect* this problem because a patch
system is in use, since otherwise it doesn't know enough. However, you
should *always* have been doing this for exactly the reasons that you
explained in your last message -- patching aclocal.m4 is not sane.
lintian has detected a latent bug in your package now that it has more
information about what's going on.
> OK. It's a bit like collateral damage - need a patch to configure,
> patching causes configure --recheck which modifies aclocal.m4 so delete
> aclocal.m4. Hmmm. I don't like it but I'll do it anyway.
Well, if I were patching configure, I'd run the full autotools suite
myself before running configure rather than relying on configure
--recheck.
>> Absolutely not -- you're introducing unexpected changes to the packaging
>> diff file,
> Well my point is that the change is entirely expected (because the patch
> modifies a file that is involved in generating the changes) - the
> changes are merely a consequence of the patch.
You expect to have a giant patch to generated files in your *.diff.gz of
your source package? I wouldn't -- that's what I meant by unexpected.
> It feels wrong to have to add a clean rule for aclocal.m4 as a direct
> result of patching configure.ac when aclocal.m4 was not a problem before
> the patch.
Well, this is just how autotools work.
> 13 out of 27 files modified by gtk-doc.
What's the diff? What is it doing to the files at build time?
> The way gtk-doc works is that it adds a pre-defined gtk-doc.make file
> into the upstream source and it is this file that determines everything
> about how gtk-doc works. If upstream are using a different version, I
> don't see what can be done. --enable-gtkdoc will update the .make file
> according to the installed version on the build system. Disabling gtkdoc
> means packaging outdated documentation.
I'm not sure how this is related. Is the update of the .make file somehow
causing the changes to the SGML file?
> It seems to me you're expecting gtk-doc-tools to implement something
> like AM_MAINTAINER_MODE where upstream gtk-doc-tools is allowed to make
> changes to doc/tmpl/*.sgml but Debian gtk-doc-tools is not. (I always
> thought that AM_MAINTAINER_MODE was considered harmful for precisely
> this reason.)
No, no, no. I'm expecting something much more simple: any file in a build
tree should be either a generated file or a source file. Surely not both!
A normal build of an upstream package should not modify upstream source
files that have no other origin.
> AFAICT this is not a fault upstream - the tmpl/*.sgml files need to be
> included. I suspect it is merely because upstream don't happen to use
> the same version of gtk-doc-tools. The "they" in the quoted paragraph
> refers to the gtk-doc-tools upstream, not libgpewidget upstream.
Changing the version of a tool should not result in an in-place edit of a
file with no other source. That's just nuts. If those are generated
files that come from some other origin, you should be able to delete them
and regenerate them from scratch. Otherwise, if upstream is shipping
them, it doesn't make sense for a normal build to modify them.
I suspect that there's some way to generate those files that just isn't
part of a normal build, and deleting them really is the right thing to do;
you just need to be more aggressive about regenerating them. But
hopefully someone who knows how gtk-doc-tools work can weigh in here.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: