[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging xmlrpc-c

Eric Kidd <eric.kidd@pobox.com> writes:

>   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.

Well you have to take your pick how much brokenness you'll still work

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?

I'd rather have users yell at the distros that ship a broken expat
than having Debian users pay the price for that.

>   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.

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)

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.

>   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.

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

That's a good measure, although I'd obviously prefer (A).


Attachment: signature.ng
Description: PGP signature

Reply to: