On fredagen den 18 september 2009, Eugene V. Lyubimkin wrote: > Magnus Holmgren wrote: > > I propose a new control field called e.g. Supersedes that will provide > > the same semantics. In its simplest form, a renamed package will declare > > that it Supersedes the old package name. That will be considered > > equivalent to conflicting with/replacing earlier versions of the > > superseded package, as well as providing a new version of it, just like a > > dummy package. Multiple packages can supersede the same package (but they > > should probably be the same version), and one package can of course > > supersede many others. > > I support this, however with not implying Conflicts/Replaces/Provides when > Supersedes is specified. Supersedes would be just a 'proposal' to a package > manager to remove old package name and install the new one, i.e. explicitly > declared upgrade path.
You have a point, though I think that in the vast majority of cases the superseding package will in conflict with the superseded one. Supersedes should definitely not imply a Provides (with the current meaning), since that would interfere with the introduction of a new, unrelated package with the old name (although versioned dependencies can be used to solve ambiguities, and all packages that formerly depended on the old name must be updated to depend on the new name instead). Evidently letting a new package take over the name of another package without at least one release cycle in between is not something that should be recommended... -- Magnus Holmgren holmg...@debian.org Debian Developer
signature.asc
Description: This is a digitally signed message part.
