On Thu, Jun 28, 2001 at 01:32:16PM +0200, Robert Bihlmeyer wrote:
> Ardo van Rangelrooij <[EMAIL PROTECTED]> 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
