[xml/sgml-pkgs] Expat 2.0.1 packaging

[Bryan Donlan]

On Wed, Jun 20, 2007 at 08:58:54PM -0600, ardo at ardolabs.com wrote:
[snip]

> > 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.

I prefer dpatch, because it makes it more clear what changes are made to
the upstream sources, and more importantly, it has a place to explain
why. Using it for autotools also helps keep config.* update cruft from
making the .diff.gz hard to read.

> >    * 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.

Ah, I see that now. Is the configure.in bit needed, though? The upstream
scripts still make a libexpat.so.1, and the debian libexpat1.links then
links to it from libexpat.so.0, so I'm not sure how I've broken the
world any more than it was before. Still, I can see why you'd want to
fix it now.

> 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.
> 

[snip]

> 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.

Okay. I'm currently investigating exactly how many packages currently
depend on the libexpat.so.0 symlink, which (though a bit fragile) would
provide a path that might be a bit easier to transition through (there's
about 6000 binary reverse-depends to deal with...). OTOH, I can
understand if the release team would prefer to do things properly and
binNMU all the dependents. I'll take a look at any header changes after
that's done.

> > 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.

I've registered as bdonlan-guest :)

> 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! :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debian-xml-sgml-pkgs/attachments/20070621/a79377ae/attachment-0001.pgp