[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).


Reply to: