>>>>> "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. 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. - J< -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
