Eric Kidd <[EMAIL PROTECTED]> 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 around. 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) suitable. 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). -- Robbe
signature.ng
Description: PGP signature
