Re: Generated changes and patch systems
Neil Williams <codehelp@debian.org> writes:
> On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
>> Lots of other packages do this -- one of mine off the top of my head is
>> xml-security-c.
> Nope. No mention of aclocal.m4 in debian/rules for that package,
> just /usr/share/misc/config.guess and config.sub.
Uh, it's the same problem. Surely the generalization is obvious?
I guess look at shibboleth-sp if it's not....
> I need to patch configure and configure.ac in this package, that means
> that aclocal.m4 is constantly being changed and reverted. It shouldn't
> matter - it really should not.
Right, so delete it in the clean rule.
> I see no purpose in lintian (or dpkg come to that) testing for changes
> in aclocal.m4 - IMHO it should simply be exempt from this check.
Absolutely not -- you're introducing unexpected changes to the packaging
diff file, and that's exactly the point of this check. Delete the
modified and regenerated files in the clean rule and then you won't have
this problem.
> No distro can risk patching aclocal.m4 - by it's nature it is transient
> and volatile and subject to large changes entirely at the mercy of
> external factors. Any build system that tries is simply going to break
> constantly, AFAICT.
Exactly, which is why lintian is making sure that you don't introduce
patches to it in your *.diff.gz inadvertantly, since it's not a sane thing
to do when you're using a patch system. The preferred method to handle it
as far as I'm concerned is doing what you're doing -- running autotools at
build time. In that case, you need to remove the regenerated files in
your clean rule. The other way to do it, particularly if you need a very
specific version of autotools, is to run them yourself and save them as a
patch, but I think that's a bad idea except in very specific situations.
>>> I really don't want to do all that for the tmpl/* files as well - I
>>> don't see the need, copying dozens of files into foo.safe or
>>> foo.upstream and then moving them back?
>> Just delete them then.
> ??? That simply does not work. The problem is that running gtk-doc not
> only requires tmpl/*.sgml files to exist but it *then modifies them*!
This is extremely unusual. Are you *sure* that it does an inplace edit of
the files during the build process? This is almost never what build
systems do; instead, they generate files from other files using templating
systems. They may ship the results of that operation and then redo it
during the build, in which case you need to delete the regenerated files
in your clean rule.
If they really expect the files to exist and to edit them in-place during
the build, upstream is doing something insane, and it's really something
that should be fixed upstream; a lintian warning is drawing your attention
to a very broken behavior.
> Even though I don't install these files into the package, I cannot
> delete them and I cannot move them out of the way or the documentation
> is not updated. Again, first build can be OK, second build generates a
> dozen spurious warnings (because the files are modified after the
> .diff.gz is created but cannot be reliably reverted before the next
> build).
Right, lintian is diagnosing build system brokenness. I'm fairly happy
with lintian's behavior here; what it's drawing attention to is exactly
the kind of thing that breaks repeated package builds or causes NMUs to
introduce spurious package diffs, and is something that should really
ideally be fixed.
> With these gtk-doc files, it's not so much that the tmpl/*.sgml files
> are generated but that a tool essential to the build modifies them in a
> way that cannot be patched because the results of the patches are
> variable according to that third party tool.
If the tool behaves and only behaves in that way (I haven't checked), that
tool is broken and we should fix that tool.
> The CDBS build doesn't do anything different - it's just that lintian
> doesn't produces any warnings for this check in CDBS packages, ever.
Well, yes, it does, if CDBS uses a recognized patch system, but the list
of patch systems that lintian recognizes is fairly limited at this point.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: