Oops, sent to the wrong bug report. On Wed, 2008-05-28 at 11:45 +0100, Neil Williams wrote: > On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote: > > 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? > > 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. > > > > 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. > > 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. > > > > 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, > > 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. 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. > > Anyway, the "problem" of the tmpl/* files is far more resistant. > > > >>> 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? > > $ ls libgpewidget-0.115.orig/doc/tmpl/ -1 > colordialog.sgml > color-slider.sgml > dirbrowser.sgml > errorbox.sgml > gpeclockface.sgml > gpehelp.sgml > gpeiconlistitem.sgml > gpe-iconlist.sgml > gpeiconlistview.sgml > gpetimesel.sgml > gpewindowlist.sgml > gtkdatecombo.sgml > gtksimplemenu.sgml > infoprint.sgml > init.sgml > libgpewidget-unused.sgml > picturebutton.sgml > pixmaps.sgml > popup_menu.sgml > popup.sgml > question.sgml > smallbox.sgml > spacing.sgml > stylus.sgml > translabel.sgml > tray.sgml > windows.sgml > > From the build log: > gtkdoc-mkdb --module=libgpewidget --source-dir=.. --output-format=xml > --sgml-mode --output-format=xml --tmpl-dir=tmpl > > Now running lintian... > 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. > > 13 out of 27 files modified by gtk-doc. > > Copy those files back into doc/tmpl/ from the upstream source and they > are still modified at the next build. > > Add a rm -f doc/tmpl/*.sgml to clean:: and the build fails: No rule to > make doc/tmp/*.sgml > > So, yes, --enable-gtkdoc is modifying files included upstream and which > are essential to the build process. > > If I drop --enable-gtkdoc I get different contents in the > libgpewidget-doc package. > > > 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. > > Yes, that is what we might expect from build systems - unfortunately it > doesn't always work that way. > > 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. > > 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.) > > > 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. > > 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. > > It is not at all insane - every package using gtk-doc-tools has the same > process. I'm not sure why only libgpewidget is currently showing this > problem but it is wrong to call it "insane". > > gtk-doc-tools is, in essence, an upstream tool. It is meant to modify > upstream files during the build, that is the reason it exists. The need > to run it in the build arises, I'm presuming, from a difference in the > version of gtk-doc-tools between Debian and the libgpewidget upstream > team. Debian simply cannot stipulate that a certain version must be used > upstream. I don't see the bug. > > > 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. > > Well, I'm not sure that it can be fixed - other than requiring upstream > to use the same version of gtk-doc-tools as Debian which is frankly, > absurd. > > > > 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. > > It probably is behaving that way but there's no accounting for changes > between versions - or for changes that may yet be made that also tweak > the output. I simply cannot risk patching these tmpl/*.sgml files and > having the patches fail at some point in the future, turning a bug in > lintian into a FTBFS in libgpewidget (which has 40 reverse > dependencies). > > I still think that lintian is out of line here - this is not a problem > for the maintainer and it is only the maintainer who needs to worry > about updating the package from 0.115 to 0.116 and 0.117 etc. > > These files are in the .diff.gz because of the behaviour of a third > party tool which updates a data source within the upstream source > according to internal rules for that tool. OK, maybe that tool could be > improved but that is not necessarily trivial - especially when Debian > cannot stipulate that any particular upstream team must use a particular > version or configuration for that tool. > > I haven't been able to identify the supposed bug in gtk-doc-tools and I > don't see that it is up to me to do that - AFAICT this is something that > is not a problem in the real world and lintian is imposing unrealistic > expectations on libgpewidget. > > I'm perfectly happy with the behaviour of gtk-doc-tools in libgpewidget > (I'd like gtk-doc-tools to be workable in a cross-build environment but > that's minor because cross-builds rarely care for API documentation > anyway and it is fairly easy to disable gtk-doc if the docs are not > wanted.). If others disagree, it is up to them to file a bug in > gtk-doc-tools and work out just how it should be improved. The mere fact > of a spurious lintian warning is an annoyance, not a problem but I would > still like lintian to be more intelligent about these things, accept > that the world is not 100% perfect and not blame the messenger. > > If this is a bug in libgpewidget that I've missed, please let me know in > the usual manner, but for now I'm just going to ignore lintian for this > check. > -- 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