> > If there is no standard naming for a package or other long term naming > > compatibility requirements involved with the rename, the Provides should > > be assumed to be deprecated and short lived and removed in the distro > > release after the next one (ie. if introduced in FC-X, keep in all > > subsequent package revisions for distros FC-X and FC-(X+1), drop in > > FC-(X+2)), and the distro version where it is planned to be dropped > > documented in a comment in the specfile. Maintainers of affected > > packages should be notified and encouraged to switch to use the new > > name. Forward compatibility Provides: in older distro branches can be > > considered in order to make it possible for package maintainers to keep > > same simple specfiles between branches but still switch to the newer > > name. > > I find this section rather confusing. The way I read it, it says to drop > the Provides/Obsoletes in N+2 -- which means it won't be possible to > upgrade from N to N+2. > > What Kamil is saying is that we now have a new policy to support > updating not just from N to N+1, but also from N to N+2. This means the > Obsoletes/Provides can only be dropped in N+3. > > It might very well be that the text above is already trying to say this > and I'm just misunderstanding, but in any case I think it's worth some > rewording :) I was thinking about this as well, and understood it as following: If you rename a package during during FN lifecycle, FN users are already covered (when they installed the updates, the rename happened). What concerns us are FN-1 users. And because of this rule (that you need to keep the rename deps for two releases, i.e. FN and FN+1, and drop in FN+2), it means that FN-1 users are also covered, because they upgrade from FN-1 to FN+1. But I'm not 100% sure that that's really the intended meaning. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
