Re: Packaging xmlrpc-c

[Eric Kidd <eric.kidd@pobox.com>]

On Thu, Jun 28, 2001 at 01:32:16PM +0200, Robert Bihlmeyer wrote:
> Ardo van Rangelrooij <ardo@debian.org> writes:
> > Well, as maintainer of the expat and libxmltok packages I would
> > really appreciate it if you could make an effort to use the
> > standalone copy.
> 
> What he said! It avoids code duplication, is more elegant, and most
> importantly: it won't lock users into a particular library version,
> needlessly. What if I want to use your library, and a modern version
> of libexpat in the same program? As long as you include your own expat
> version, this will either simply break, or work with some tricks, at
> the cost of increased memory footprint.

Let me brainstorm about possible solutions.  First, here are my hard
constraints as the upstream maintainer.  If these can't be satisfied, I
can't release Debian packages.

  1) xmlrpc-c applications must run on any libc6 i386 Linux distribution
     without recompilation.  The only current exception to this is
     applications which use the w3c-libwww client module, which will be
     going away for exactly this reason.

  2) xmlrpc-c applications must run on distros which provide a copy of
     libexpat, and ones which don't.  Since the libexpat sonames have not
     been incremented in a correct manner on all distributions, it's
     extremely hard for me rely on pre-installed versions of expat.

  3) xmlrpc-c uses expat to parse potentially hostile network data, so it
     must rely on stable, well-audited versions of expat.  Right now, this
     means using James Clark's 1.x packages, not the 1.95 development
     series.

Your constraints:

  4) It must be possible to write applications which use both xmlrpc-c and
     the Debian version of expat.

Possible solutions:

  A) Make xmlrpc-c use the Debian version of expat.  This would violate
     constraints (1), (2) and (3).
  B) Use the current xmlrpc-c setup.  This would violate constraint (4).
  C) Rename all the symbols exported by xmlrpc-c's version of expat to
     co-exist with other versions of expat.  I can do this in the upstream
     source the next time I change sonames.  This doesn't violate any of
     the above constraints, but it *does* cause xmlrpc-c applications to
     have a slightly higher memory footprint (about 100K, shared by all
     xmlrpc-c applications).

All things considered, my preference (as the upstream maintainer) leans
strongly toward (C).

Basically, the copy of libexpat in xmlrpc-c is private, and I'd very much
like to keep it that way.

> For an example of real life breakage, look at apache. It gratuitously
> includes its own "expat-lite" library. Once you use it together with
> mod_perl and some perl XML stuff (which in turn depends on a recent
> libexpat): segfault.

This is bad, and I'm happy to work around this problem.

Cheers,
Eric