Why do we need FC version attached to the package name?

[Adam Williamson]

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