On Thu, Sep 08, 2005 at 04:58:07PM -0700, Chuan-kai Lin wrote: > On Thu, Sep 08, 2005 at 09:06:36AM -0700, Brian Nelson wrote: > > The current libfam0 provides the previous libfam0c102, presumably > > because libfam is a C++ lib but only exports a C interface, so the > > transition for GCC 4 was unnecessary.
> Yes. > > However, the libfam0c102 in sarge provides libfam0. This means that > > that package completely satisfies any package in etch that depends on > > libfam0 (with the exception of those that have a versioned dependency > > on libfam0, like libfam-dev). The consequence is that an "apt-get > > dist-upgrade" or equivalent will *not* install libfam0 but will keep > > libfam0c102 around instead. > If I understand things correctly, the dist-upgrade behavior will happen > regardless of whether libfam0 provides libfam0c102 or not. Is that > observation correct? So what would happen if (suppose) we do need the > g++-4.0 transition and libfam0 does not provide libfam0c102? So, the situation here is that all packages in sarge Depend: on libfam0c102, and the libfam0c102 package Provides: libfam0. In sid, packages currently being rebuilt Depend: libfam0. So yes, there is currently nothing which forces the removal of the outdated libfam0c102 and the installation of libfam0 on upgrade from sarge. > > This is an exceedingly odd situation. The only solution that seems > > satisfactory to me is to go back to the sarge-style packaging, meaning > > kill the libfam0 package and re-introduce libfam0c102. > The situation is indeed pretty odd. Suppose we kill libfam0 and then > re-introduce libfam0c102. What would happen to those people that has > libfam0 2.7.0-8 installed on their system? Same problem, but confined to unstable. I think this is the best solution, though, as sid users should be well accustomed to dealing with obsoleted packages on their system. The other option would probably be to keep the package name as libfam0 in etch, but cause the shlibs to declare a versioned dependency on libfam0 (>> $some_value), since this dependency won't be satisfied by a Provides:. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
