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
been suggested but that just masks the problem and may cause unwanted
downgrades. Any solution either involves severly limiting what kind
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:
and so on. In addition, Cooker gets an automated rebuild of all
at the start of each new release cycle, so in practice, packages for
release are always newer than any official update for the previous
Backports can theoretically be versioned so that they'd have the
problem, but in practice it doesn't often happen (and hey, backports
unsupported anyway, you get to keep both pieces!).
The problem with this method is it involves a bit more work, because
can't just send the exact same build to Rawhide and to a stable
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
that actually happen, though.