On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote: > If you have any ideas I'd like to hear them. A super epoch has already > been suggested but that just masks the problem and may cause unwanted > downgrades. Any solution either involves severly limiting what kind of > updates can be done or requiring network access during upgrades. Mandriva versions updates like this: 1.0-1mdv2009.1: initial package release in 2009 Spring 1.0-1.1mdv2009.1: first update 1.0-1.2mdv2009.1: second update ... and so on. Meanwhile, in Cooker (development branch), it'll be proceeding like this: 1.0-2mdv2010.0 1.0-3mdv2010.0 and so on. In addition, Cooker gets an automated rebuild of all packages at the start of each new release cycle, so in practice, packages for one release are always newer than any official update for the previous release(*). Backports can theoretically be versioned so that they'd have the update problem, but in practice it doesn't often happen (and hey, backports are unsupported anyway, you get to keep both pieces!). The problem with this method is it involves a bit more work, because you can't just send the exact same build to Rawhide and to a stable release together. I suppose it might also be a bit tough to police automatically: MDV updates are gatekeeper-ed by the security team, so this is policed manually there (if you don't version your candidate update package properly, it doesn't get sent out as an update, and you get an email telling you what you did wrong). * - except if the automated rebuild somehow failed, and that package never got touched again in Cooker before the next stable release, but did get updated in the previous stable release. I've rarely if ever seen that actually happen, though. -- adamw -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
