On Fri, Sep 09, 2005 at 01:04:34PM -0700, Chuan-kai Lin wrote: > On Thu, Sep 08, 2005 at 09:42:28PM -0700, Steve Langasek wrote: > > > > 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:. > How about making the fam source package provide both libfam0c102 and > libfam0, with the former as a transitional dummy package to the latter? Can be done, but I didn't offer that option because I don't really like it. :-) At that point, I don't really see any reason to change the package name from what it was in sarge. (There never was a good reason, but it was done anyway because people didn't realize it was a mistake, and the name change was allowed to stand because it didn't seem to cause any problems.) -- 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
