Re: Bug#116727: Problem with libexpat & php
On Tue, Dec 04, 2001 at 04:37:25PM +1000, Anthony Towns wrote:
> On Mon, Dec 03, 2001 at 09:48:26PM -0600, Ardo van Rangelrooij wrote:
> > 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?)
>
> I'm sorry, but it's too late to start transitions like this for
> woody. (And has been for almost a month now, see [0]).
Ok, but I don't see any reference to optional in [0], only base and standard.
Maybe you should send out an updated freeze schedule for optional and extra.
> You need to expect to support having "Depends: libexpat1" imply
> libexpat.so.1, libexpat.so.1.0.0 and libexpat.so.0 are all the same
> library and are what upstream apparently calls libexpat.so.0.1.0. You
> may wish to ask upstream to skip .so.1 so as to cause less breakage on
> Debian systems; but otherwise you'll have to do something like make a
> libexpat1g package that conflicts with libexpat1, and put all this down
> to a learning experience.
Ok. Hmm, and all this only because some NMU f**ked up. Oh well.
I'll at least upload a new version with the autotools-dev approach in place
and the missing manpage for the binary in the packagei (this just got in).
Thanks,
Ardo
Reply to: