> 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.