> KP> I wonder why nobody responded. Is something unclear? > > Well, fundamentally I don't think this has much to do with the mechanics > of packaging. > > Fedora has an existing updates policy, drawn up by FESCo, at > https://fedoraproject.org/wiki/Updates_Policy. I don't think having > something on the same topic but saying something different and dictated > by a different committee is productive. > > If there's some specific statement of just _how_ someone should package > something in order to support updating across two versions, then that's > a reasonable thing to put in the packaging guidelines. (Yes, there > might be stuff in the guidelines now which probably doesn't meet this > criterion; that's no reason to add more.) I can't think of any general > rule, though. > > Current the guidelines don't have much to say about updates; they > discuss scriptlets and how they can tell if they're being run as part of > an update (as opposed to a fresh installation). They talk about > %changelog entries that you make when updating something, and mention > the inclusion of CVE info when making security updates. There's > information about updates of packages requiring bootstrapping with > prebuilt content. There's nothing about _when_ to push updates. > > - J< > Thanks for your response. I didn't even consider https://fedoraproject.org/wiki/Updates_Policy before. I was more thinking about the "rpm dependencies" topic here than high level update policy. Something that would define that if you e.g. replace one package with a different one, the Obsoletes and Provides must not work just across one release, but across two (this is very specific, but serves as an example). Or that you can't break dependencies some other way. Along those lines. But I guess it also makes sense to consider this being a high-level requirement that doesn't talk about low-level issues and would fit into the Updates Policy document (not sure which way is better). My original problem remains, though, that document does only seems to talk about updates during the product lifecycle, but doesn't talk about upgrading from FN to FN+1, so I don't really know where FN -> FN+2 upgrades would fit in there. So if you think the Update Policy is still a better place for such things, I'll redirect my question to FESCo folks. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
