[xml/sgml-pkgs] Expat 2.0.1 packaging
Bryan Donlan
bdonlan at fushizen.net
Thu Jun 21 21:08:57 UTC 2007
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
More information about the debian-xml-sgml-pkgs
mailing list