Re: need help in resolving the Apache-Expat-XML::Parser conflict
Jonathan McDowell (firstname.lastname@example.org) wrote:
> On Sun, Sep 09, 2001 at 03:51:05PM -0500, Ardo van Rangelrooij wrote:
> [AxKit not working due to Apache expat linkage]
> > I've no problem NMU'ing apache, but that might break other packages
> > (which?). There are two ways to NMU:
> > 1. leave out expat: this is the simplest way since it only requires a
> > small change in the debian/rules file
> > 2. build with the least version of expat (as described in bug #96093):
> > that's more work given the way it's currently packaged (the upstream
> > source are in tarballs which are unrolled during build)
> > Any help in resolving this situation is greatly appreciated.
> Option 2 isn't actually that hard to do - you can put a patch against
> the tarball in debian/patches and it'll get applied when the tarball is
Ok, I didn't get that easily from looking at the the rules file.
> unrolled. However why is Apache build with expat? Surely either option 1
> removes functionality or doesn't and if it doesn't then is there any
> reason not to choose it over linking expat dynamically? And if it does
> then Option 2 makes more sense.
I completely agree. IIRC it's there for e.g. libapache-mod-dav. I'll contact
the respective maintainer. Maybe that package can very well function without
expat in apache and then it's probably best to simply remove it.
Another good thing would be to move all packages currently build against the
old version of the epxat libs (libxmltok1) over to the new version. But we
still have then some packages with their own version build in (just like
apache has right now), like the xml-rpc packages. Those can still be a
potential problem. But once apache is updated to either the new expat or to
without expat these problems move to those packages.
To be continued...
Ardo van Rangelrooij
home email: email@example.com
home page: http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9