Magnus Holmgren wrote:
> 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).
>
Nevertheless, there were no precedents (?) for some fields implying others,
and I think there is no good reason to introduce it.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer