On Sun, Nov 1, 2015 at 12:16 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 31 Oct 2015, at 7:48 PM, Michael Felt <mamf...@gmail.com> wrote: > > > I would like to repspond positively on this suggestion that "something" > be done. > > It could be updated, and fortunately expat is not a package with > frequent (security) updates, > > but it is external. What may have been good before is perhaps not as > correct anymore. > > > > a) expat needs to be closer to mainstream: there are many features > > in expat that have been introduced since then. > > The embedded expat is not packaged as an internal (aka static) library - > but appears as a separate library. > > > > I ran into this problem when packaging something else that needed the > latest and greatest (i.e., 2.0.1 as base). > > > > My solution is to repackage apr, apr-util and httpd after removing > > the internal expat - so that I have latest and greatest for both - and > can update it, > > in principle - separate from apr. > > > > I would vote to make external expat the default and/or just remove expat > from apr. > > Unfortunately our version rules forbid the removal of expat from > APR(-util) v1.x, as this would break APR for people who are using expat > already. > > Adding the option to link to an external expat is definitely an option, on > condition there is a backwards-compatible guarantee on behaviour from the > APR library. > Philosophically, we cannot remove apr_xml functionality or compatibility, and we don't change build options across subversion bumps (1.5.x to 1.5.y is always expected to 'just work'), but there is precedence for changing the build schema between minor versions, as long as the resulting apr still offers backwards binary compatibility, and we document in CHANGES. E.g. we could remove expat from the bundle of 1.6.0, and insist the user obtain this themselves, either the final expat 0.9 or a later expat 2.1 depending on the level of sub-dependency compatibility they require. They even have the option of pick libxml2 if none of their code has a dependency on entry points in expat itself (we never made such a promise, and that goes for openssl, ldap, etc). We've long supported expat 2. I don't think I've built from apr's expat sources since the mid null'sies. But it won't be removed from apr 1.5.next, for the reasons Graham points out.
