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 (rra@debian.org) 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 have been changed, hence no patches. This, to me, is where the "all changes are patches" approach falls down. A patch, IMHO, is a deliberate action - similar to a GnuPG signature on an email. It should require a conscious act to solve an identifiable problem - preferably one with a bug report. Changes that result merely from differences in build environment between upstream and Debian should not even be in the .diff.gz if at all possible - such changes are, IMHO, certainly not deliberate actions by the maintainer. Changes that themselves change independently of the actions of the maintainer cannot be implemented by the maintainer as patches, imho. The "silent" build is available from my repo: dget -x http://www.linux.codehelp.co.uk/packages/pool/main/libg/libgpewidget/libgpewidget_0.116-1.dsc I won't upload to ftp-master just yet - I do need to do some more tests to ensure that other GPE packages build and function correctly so that I don't inadvertently trigger a transition in over 40 packages. ;-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part