>>>>> "KP" == Kamil Paral
KP> Thanks for your response. I didn't even consider
before. I was more
KP> thinking about the "rpm dependencies" topic here than high level
KP> update policy. Something that would define that if you e.g. replace
KP> one package with a different one, the Obsoletes and Provides must
KP> not work just across one release, but across two (this is very
KP> specific, but serves as an example).
That case is covered specifically:
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
KP> Or that you can't break dependencies some other way. Along those
There's also text like:
For example, Fedora packages are only required to retain historical
provides for two full release cycles.
Thanks for these examples, that's why I had in mind, I just didn't see it in the
guidelines. I'm glad that it's in there.
So I think the guidelines do cover the necessary cases of when you can
remove things from the spec which were there in order to facilitate
two-version upgrades. However, if you think something specific is
missing, please do let us know.
If we find out something that's not covered, I'll let you know, but in general the
packaging guidelines seems to contain necessary bits already. Thanks for your help.