Re: Bug#116727: Problem with libexpat & php
Anthony Towns (aj@azure.humbug.org.au) wrote:
> On Wed, Nov 07, 2001 at 11:02:51PM -0600, Ardo van Rangelrooij wrote:
> > So let me get this straight: you reopen these without even really knowing
> > for sure whether it actually is still a problem? Next time please do your
> > homework better.
> >
> > The fix is in sid and waits for transfer to woody. The in your opinion
> > krude hack has been proposed by Anthony (Towns) himself.
>
> Ugh. For reference, I don't know all that much about expat, and I haven't
> researched the reasons for the so-name change. The suggestion was based
> on reports that the symlink worked as far as users were concerned,
> and the vague rumours I've heard about why it broke.
Ok. It broke because someone doing an NMU to get it to work on the ia64
platform changed a variable called LIBAGE in the configure.in file which
causes the soname to be increased by one. This was not mentioned in the
changelog so I didn't pay close and immediately attention. Shortly after
the build daemons took care of spreading this throughout the whole system.
When the first bug reports came in it was already too late to stop it.
I'll take this person outside and a few times around the block. ;-)
> And it's definitely a crude hack. At best it's one that *works*.
I completely agree.
> (Additional problems to look forward to: incompatibilities with other
> distros who supply expat as libexpat.so.0.1.0; incompatibilities when
> libexpat.so.1.0.0 is released: you can't have a system with both libs
> installed at once)
I'm aware of that. I plan to fix this mess as follows:
- uploading a new version with changed (= correct) package names based on
the library soname, meaning libexpat0 and libexpat0-dev
- uploading two dummy packages whose sole purpose are to provide a smooth
transition: libexpat1-dev which is only dependent on libexpat0-dev and
libexpat1 which is only dependent on libexpat0 and has the formentioned
symlink
- file bug reports against all dependent packages to change (for the 2nd
time :-( ) their dependencies (which severity is appropriate here?)
- after transitioning all dependent packages remove the dummy packages
(the safest is probably to wait until they all made it into testing)
I'll also work on using the autotools-dev approach to reduce the risk of
being NMU'ed for porting reasons.
A funny sidenote: on one of the expat mailing lists there was a request
to change the soname to 1.0.0. Oh well, at least the plan above allows
us to handle that situation.
Thanks,
Ardo
--
Ardo van Rangelrooij
home email: ardo@debian.org
home page: http://people.debian.org/~ardo
GnuPG fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Reply to: