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
signature.asc
Description: OpenPGP digital signature
