Re: intent to rename vips7.10 -> vips
On Mon, 17 Jan 2005, Anthony Towns wrote:
> libvips-tools and libvips-doc likewise can probably lose their
> version happily, presuming people who Depend: on libvips-dev today,
> and end up getting the tools from soname 11 aren't going to be
> unhappy. But for both of those you should be able to just have
> "libvips-* Conflicts:/Provides:/Replaces: libvips7.10-*" to satisfy
> > Each package Conflicts with the package it
> > replaces with a version << the future dummy transition version of the
> > existing packages and Replaces the old package as well. For example:
> I'm fairly sure the above should ensure you don't need any dummy
> packages, and gain all the benefits you were aiming for.
The point is not about "needing" dummy packages or not. We could well
state that people should read the release notes and select the new
packages by hand to be installed. But this would be bad.
The point is whether dummy packages are useful, and yes, they are
useful indeed. Unless things have changed recently, dselect does
*not* select a new package to be installed, no matter how many
Conflicts:/Provides:/Replaces: on the old package it has.
So yes, we *need* dummy packages for upgrades to be smooth.
> Dummy packages are almost always evil.
I strongly disagree. They are currently the only way to tell the
package manager that the new packages should be installed when you
have the old ones in the system.