Generated files and patch systems
I'm getting into a crazy situation with this lintian warning: patch-system-but-direct-changes-in-diff I've removed one diversion from libgpewidget but I still need to use one and this requires a patch to configure.ac using dpatch. This then regenerates configure and aclocal.m4. I think patch-system-but-direct-changes-in-diff is just too buggy to be deployed - that isn't the fault of lintian, I think the problem cannot be detected/determined in a sane manner. Maybe a downgrade to info? From #471263 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. -- Russ Allbery ([EMAIL PROTECTED]) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471263#10 So I am running the relevant autotools at build time but I still get the warning. Then a more bizarre problem arrives - the first build I get: Now running lintian... W: libgpewidget source: patch-system-but-direct-changes-in-diff aclocal.m4 Finished running lintian. Any subsequent build produces: Now running lintian... W: libgpewidget source: patch-system-but-direct-changes-in-diff aclocal.m4 W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/color-slider.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colordialog.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colorrenderer.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpeclockface.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpedialog.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpehelp.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtkdatecombo.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtksimplemenu.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/libgpewidget-unused.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/link-warning.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/pixmaps.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/smallbox.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/spacing.sgml Finished running lintian. I don't see why I should patch aclocal.m4 and I consider it a harmful thing to do seeing as every update of autotools will likely cause the other changes in aclocal.m4 and the patch will to fail to apply causing a FTBFS - a much more serious issue. Having aclocal.m4 in the .diff.gz causes problems with uscan; uupdate because it does fail to apply from one upstream release to the next but that is only a problem for me and I can live with it. What is the solution here? Do the other dpkg source formats have a solution for generated files? (PLEASE don't spout on and on about git. I don't use git, I have no intention of using git - I do not particularly want to use any RCS with this particular package although I might consider SVN seeing as svn-buildpackage at least has sane MergeWithUpstream support. The more noise the git-fanclub make, the less I listen so don't expect a reply from me if you want to talk about git.) Do I have to move aclocal.m4 aside in debian/rules and move it back? How does that help? - it'll still be in the .diff.gz under a different filename. That doesn't help the build-twice release goal issue. Yes, the package meets the letter of the release goal by building twice in a row but not without either spurious lintian overrides or spurious lintian warnings. What is the problem that this lintian check is trying to solve, why does it apply to generated files and is there a sane way to tell the difference (especially when a generated file can still mean a file present in the upstream source and modified in the .diff.gz because modifications result from the actions of a third-party build-tool)? I'm not sure why gtk-doc-tools is making these changes - this is a new upstream release (although there appear to be differences in the autotools environment between myself and upstream, hence the aclocal.m4 diff) and the tmp/ files have been updated upstream. Quite why I get no error with the first build but errors with all subsequent builds I have no idea. I can reproduce the silent build by simply copying the tmp/*.sgml files back into place from the .orig.tar.gz so those could be moved aside as well but it seems a lot of work if the lintian warning itself is dubious or cannot be applied in a sane manner. I don't see that creating patches for these tmpl/ files is correct either - a change in gtk-doc-tools could easily break many such patches and I do not consider it my fault that those files
Re: Generated files and patch systems
On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote: So I am running the relevant autotools at build time but I still get the warning. If you run autotools at build time you should also ensure that the changes which autotools makes are reverted in the clean target. This means that your diff doesn't get cluttered with automatically generated things and ensures that repeated builds of the package produce the same diff.gz. This is the same idea as patch systems reverting the changes they make in the clean target. Do I have to move aclocal.m4 aside in debian/rules and move it back? How does that help? - it'll still be in the .diff.gz under a different filename. That doesn't help the build-twice release goal issue. Yes, the package meets the letter of the release goal by building twice in a row but not without either spurious lintian overrides or spurious lintian warnings. If you actually move it back in the clean target (rather than just copying it back) then it won't appear in the diff.gz. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Generated files and patch systems
On Sun, 25 May 2008, Mark Brown wrote: On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote: So I am running the relevant autotools at build time but I still get the warning. If you run autotools at build time you should also ensure that the changes which autotools makes are reverted in the clean target. This means that your diff doesn't get cluttered with automatically generated things and ensures that repeated builds of the package produce the same diff.gz. Exactly, it's the reason why I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482716 in the first place. Removing the files which are regenerated in the configure stage is a simple way to make sure that that you don't end up with such clutter. Several of the packages which contain such useless changes in the diff end up causing problems once you try to convert them to source format 3.0 (quilt) because the changes can't be applied/unapplied at any point of time if the files are regenerated by some intermediate step. Some examples: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482749 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482733 So I'm in favor of keeping this lintian warning because if the maintainer makes the effort to keep clean patches, it should also make the effort to make sure that the package cleans up nicely and doesn't clutter the .diff.gz. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
