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


On Thu, Mar 04, 1999 at 09:03:34PM +0100, Gergely Madarasz wrote:
> > Wouldn't it be less harmful if I made this new version with names
> > changed - because xpm4g 3.4j-0.8 and libxpm4 3.4k-1 don't share any files
> > (I think so, but I'll check). Everything that just needs libXpm.so.4.10
> > works, and everything that just needs libXpm.so.4.11 works.
> The soname is libXpm.so.4 in both cases (probably, I can only check the
> current version), so those symlinks conflict.

Yes, and that is the only problem and only file common in both libs.
It can be dealt with with simple preinst/postrm.
The binary compatibility is there, all programs compiled against so.4.10
work with so.4.11.

> Unless we get versioned provides, I'd suggest a name change when the
> soname changes, then there won't be any problems with broken versioned
> depends, because the packages will have to be recompiled (and if the
> soname changes the package name changes too anyway)

The problem is that the soname will not change, ever. Okay, if someone
thinks of a new XPM standard, but that ain't likely to happen RSN.

> And about the problem mentioned by Santiago (dpkg doesn't support package
> renaming), it does not apply here, because this is only a library package,
> you'd install it only because of dependencies.

I don't follow. Dpkg supports package renaming, but it and dselect will
not automagically find the new version with which to replace the old.
So, if I renamed xpm4g-dev to libxpm-dev, to get it installed I'd have
to play dirty tricks with other dependencies, and noone wants that.
Plus, there is the problem with versioned dependencies when provides
don't work (why we need versioned depends).

Anyhow, I've decided not to rename anything, for now. When dpkg/dselect
support it properly, then I'll do it.

Expect an upload of xpm 3.4k to potato RSN.

enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Reply to: