[xml/sgml-pkgs] Expat 2.0.1 packaging

[ardo at ardolabs.com]

> Hello,
>
> After seeing a friend (new to linux in general) struggling to build a
> recent version of expat manually, I looked into the packaging situation
> on debian's end, and found that the (co-)maintainer (ardo at debian.org)
> hasn't
> performed an upload since 2005-04-20, and in the meantime upstream has
> released several newer versions (current is 2.0.1). ardo, if you're still
> around, would you mind if I helped out as (another) co-maintainer?

I'm still here.  I've just been way too busy with real life events and
such the last two years.  That's over now and I'm slowly working my way
back into a more active participation.

> In any case, I decided to try my hand at updating the package myself, and
> did
> a bit of cleanup while I was at it. My results are at:
>   dget http://www.fushizen.net/expat/expat_2.0.1-1.dsc
>
> Here is the changelog:
>  expat (2.0.1-1) unstable; urgency=low
>  .
>    * New upstream release (Closes: #245840, #429175)
>    * debian/rules, debian/control: Add dpatch framework
>      = debian/patches/01_autotools_update.dpatch: Move autotools file
> updates
>        into a reversible patch, so as to make rebasing patches easier
>        (also add automake-1.9, autoconf, and libtool to control)
>      = debian/patches/10_install_expat_config.dpatch,
>        debian/patches/20_xmlwf_exit.dpatch,
>        debian/patches/25_xmlwf_manpage.dpatch: Split out diffs

Hmm, converting to dpatch?  Is that the trend these days...???  Oh well.

>    * configure.in: Drop .so version hackery, and use upstream's values.

And now you've broken the world (that is, the world according to Debian).

As I said in my reply to your bug report: Due to a major screw up in an
NMU many moons ago, expat in Debian has TWO sonames: 0 and 1.  See the
Debian changelog for this.

This is a major issue in an upgrade to a newer version.  The ideal
situation would be to upgrade to a expat version that has a soname of '2'.
 But that might take quite a while.

See more below.

>    * debian/rules: Replace incorrect usage of $(PWD) with $(CURDIR)
>    * debian/control: Replace Source-Version substvar with binary:Version
> for
>      binNMU-safety
>    * debian/rules: Ensure all examples are non-executable
>    * doc/xmlwf.1: Remove incorrect statement to the effect that XML
>      declarations are mandatory for well-formedness. (Closes: #412786)
>    * debian/control: Remove Provides: libexpat1 clause for the udeb
>      (Closes: #419606)
>    * debian/control: Update to standards-version 3.7.2.2 (no changes)
>    * debian/rules, debian/libexpat1.lintian-overrides,
> debian/libexpat1.install:
>      Override lintian warning caused by udeb lines in libexpat1's shlibs
> file
>    * debian/rules: Enable test suite
>    * debian/rules: Add --fail-missing to dh_install invocation
>    * Acknowledge NMUs (Closes: #355937, #354244, #342684)
>
> There are a few things I'd appreciate review on, though:
>    * Is the shlibs for the udeb correct? I removed the manual one and
>      left the generation of the shlibs file to debhelper, but I've never
>      worked with udebs before, so I'm not sure if that's correct.
>    * The previous version's diff.gz had this chunk:
>
> --- expat-1.95.8.orig/configure.in
> +++ expat-1.95.8/configure.in
> @@ -44,9 +44,9 @@
>  dnl If the API changes incompatibly set LIBAGE back to 0
>  dnl
>
> -LIBCURRENT=5
> +LIBCURRENT=1
>  LIBREVISION=0
> -LIBAGE=5
> +LIBAGE=0
>
>  AC_CONFIG_HEADER(expat_config.h)
>
>
>      What is the purpose of this chunk? The upstream values seem to be
>      compatible with existing binaries in Debian.

This chunk is the major screw up I mentioned above.  This never should've
happened.  I've never understood what the person that did this was
thinking.  The only possible explanation I can think of is that the person
thought that the soname needed the match the package name.  Wrong: the
package name needs to match the soname.  Unfortunately the timing of the
NMU was such that I could not fix this NMU screw up, as the package was
frozen for the upcoming release at the time.  Ever since we've lived with
two sonames...

A possible solution to do the upgrade would be to call the package
something  like libexpat1X with 'X' to be determined, use the soname '1'
(as in, follow upstream again) and put the proper conflicts and such in
the control file.  This would force rebuilds of all package dependent on
libexpat1, although the soname would not change.  This might work, as I
somehow got the impression on the expat mailing list that the ABI is
backwards compatible (but we need to verify this) but they just added some
new functionality to the API.  Again, we need to verify this.

We also need to run this by the release team, as they like to know which
libraries are upgrading.  And since this is a very special case, we need
to make sure that what we're going to do works.

> As mentioned above, I'm interested in helping out with maintenance of
> this package, but I will need a sponsor, as I'm not a formal debian
> developer as of yet.

(I'm a bit limited as to what I can do right now, as I'm on vacation until
this weekend. :-))

I absolutely don't mind a co-maintainer.  Please create a guest account on
alioth and we'll add you to the project.  Then please add yourself to the
'Uploaders' field.

In the mean time, please think this whole mess over, find the wholes in my
proposal, come up with a better one, and when I'm back from vacation we'll
work together on cleaning up this mess.  Welcome to the team! :-)

Thanks,
Ardo