Re: Packaging xmlrpc-c
On Fri, Jun 29, 2001 at 01:27:21PM +0200, Robert Bihlmeyer wrote:
> Would you think it a good strategy for an xmlrpc-c application to link
> statically with its own version of your library, because there are
> set-ups out there which have a too old, too new, too screwed
> installation of xmlrpc-c?
Ah! But I've been extremely careful with my ABIs, so there *aren't* any
broken versions (yet). ;-)
If I remove my library's internal, private copy of expat, I will actually
be *creating* the first known "broken" version of xmlrpc-c on any known
Linux distribution (where "broken" is defined as having the same soname but
a different ABI).
> I'd rather have users yell at the distros that ship a broken expat than
> having Debian users pay the price for that.
Expat 1.x was never packaged as a shared library by its upstream
maintainer. Therefore, any version I might find has a soname assigned by a
downstream maintainer on some distro. Since there's no standard,
everybody's right. And everybody's wrong. :-( There's nobody for the users
to appeal to in this matter.
Basically, expat 1.x was designed to be used exactly as I'm using it--as an
internal library. I actually disagree with this decision, but my life is
much easier if I respect it.
> No argument here. I assume that this requirement will be dropped/modified
> somewhen in the future, once you consider 1.95 (or 2.0, or whatever)
> suitable.
Possibly. I know, from personal experience, that James Clark typically
produces highly correct code, and expat 1.x has been used in uncountable
projects. 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, and used less extensively throughout industry.
I will make this decision when--and if--I'm comfortable with it.
> On a releated note, the security process also becomes more sluggish
> and dependent on more people. Now two persons (James and you) must fix
> their copies of expat to remove a vulnerability.
Yes. This is unfortunate. But at least expat 1.x is extremely stable
software, and the expected number of security updates is very small.
> > A) Make xmlrpc-c use the Debian version of expat. This would violate
> > constraints (1), (2) and (3).
>
> Nope. IIRC the older expat is in Debian in the package libxmltok1.
> Relying on that would satisfy (3) and (1). Probably not (2) because
> one can always find a platform where a library is not installed.
No, it still breaks constraint (1)--preserving the ABI/soname relationship
across multiple distros. Since the upstream version of expat 1.x has no
sonames, I simply cannot rely on every distribution chosing a consistent
soname for it. Hence, if I want any degree of portability, I must create
my own sonames for expat 1.x and make them part of xmlrpc-c's ABI.
(Theoretically, it might be possible to create new sonames without
duplicating the actual library code, but I have no reason to believe that
ldconfig is willing to jump through such hoops on my behalf.)
> > All things considered, my preference (as the upstream maintainer) leans
> > strongly toward (C).
>
> That's a good measure, although I'd obviously prefer (A).
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.
Once the new version of expat stabilizes, this problem may go away--*if*
the new maintainer scrupulously follows the rules for updating sonames.[1]
And if there's actually a consistent ABI for expat 2.x, then I can rely
upon it to produce a consistent ABI for xmlrpc-c.
It's simply that--in my opinion as the upstream author of xmlrpc-c--this
day has not yet arrived.
Cheers,
Eric
[1] For those of you following this discussion, you can find a good summary
of these rules under the info topic (libtool)Versioning. Libraries which
fail to obey these rules cause really ugly problems, like RedHat's libjpeg
fiasco a few years ago.
Reply to: