Re: RFS: libroxml

[Gergely Nagy <algernon@balabit.hu>]

Hi!

As promised, a couple of notes regarding the packaging:

* Is there any particular reason you're not using 3.0 (quilt) source
  format?

  Not a bug, just curious.

* debian/README & debian/control

  Most of the content is better suited for the long description. When
  the package is already installed, you don't need to prove its worth
  anymore.

  On that note, merging the README into the long description would also
  make the latter a lot more useful.

  Just by reading the long description, I'd have absolutely no idea why
  I would want to install the package, or how it differs from existing
  XML parser libraries.

* debian/copyright

  There's two issues with the copyright file: first, it refers to
  /usr/share/common-licenses/GPL instead of LGPL, and second, it refers
  to an unversioned file.

  The former is a bigger issue, which should be corrected ASAP, the
  latter is cosmetic and pedantic at best. It's trivial to correct
  though, and has no downsides in my opinion.

* debian/docs

  Why are you installing the LGPL?

* debian/libroxml0.postinst

  As far as I see, this only does an ldconfig. Something which debhelper
  will add too, on it's own. So this file could be safely removed.

* debian/rules

  Now, this is a place where I'll wreak havoc, as this is just plain
  ugly. Sorry about that, but that's how it is.

  First of all, you have a configure and configure-stamp target-pair,
  which do absolutely nothing, but touch a stamp file. Useless noise.

  Second, your build, build-arch and build-indep dependencies are,
  well... incorrect.

  You do not build any arch-indep package, yet, build-indep depends on
  build-stamp, which will also build the arch-specific
  stuff. build-indep in this case should be a no-op.

  Something like the following should simplify the building:

  build: build-arch build-indep
  build-indep: ;
  build-arch: build-stamp
  build-stamp:
  	dh_testdir
        ${MAKE} doxy
        ${MAKE}

        touch $@

  You could even remove the build-stamp target, merging it into
  build-arch, and removing the touch. A second call to it would trigger
  a new doxy build and a make run, but personally, I think that's
  acceptable. (Do note that I'm not a fan of stamp files, not by far)

And that's all, after a quick review. Apologies for my harsh words here
and there, it's nothing personal, I just happen to have a strong opinion
on what's the One True Way(tm) to do stuff. ;)

-- 
|8]