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 <[EMAIL PROTECTED]> 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

Reply via email to