> >>>>> "KP" == Kamil Paral <kparal@xxxxxxxxxx> writes: > > KP> Thanks for your response. I didn't even consider > KP> https://fedoraproject.org/wiki/Updates_Policy 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 > name. > > KP> Or that you can't break dependencies some other way. Along those > KP> lines. > > 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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
