Re: Packaging xmlrpc-c
On Sun, Jul 01, 2001 at 01:12:57PM +0200, Robert Bihlmeyer wrote:
> Eric Kidd <eric.kidd@pobox.com> writes:
> > Expat 1.x was never packaged as a shared library by its upstream
> > maintainer. [...] Basically, expat 1.x was designed to be used exactly
> > as I'm using it--as an internal library.
>
> Ah, I was ignorant of this. This makes your decision much more
> understandable to me.
Well, I'm not trying to be delibrately preverse just for the *fun* of
it. ;-)
> > A future decision to upgrade to expat 2.0 would need to involve
> > a thorough audit of the new code base, since it's maintained by a new
> > author,
>
> "cvs diff -rjclark-orig" should do the trick. Actually, from skimming
> sourceforge's webcvs, the differences seem pretty small.
This is *really* good news, and greatly increases the chances of xmlrpc-c
upgrading shortly after a new stable version is released.
> > and used less extensively throughout industry.
>
> If Debian packages are any guide, those dependant on libxmltok1 are in
> the same number as those dependant on libexpat1. Of course this naive
> check misses those statically linking the older version.
This seems to be pretty typical for free software. But if you count all
the non-free software out there, it appears that a lot more people have
studied expat 1.x.
> > If (A) were at all feasible, I'd prefer it, too. But James Clark never
> > packaged expat 1.x as a shared library, so the downstream inconsistencies
> > in various distros are a bit overwhelming from my perspective.
>
> Ok.
So (C) it is. xmlrpc-c will keep the internal version of expat 1.x it uses
on other distros, at least until 2.x is stable and audited.
But for Debian's sake, I'll hide all external symbols from this private
version of expat in a future upstream release, so Debian packages will be
able to depend on Debian's expat *and* xmlrpc-c.
Deal? :-)
Thank you very much for help on this issue!
Cheers,
Eric
Reply to: