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

Jesse Keating jkeating at j2solutions.net
Tue Jun 23 23:06:12 UTC 2009



On Jun 24, 2009, at 0:46, Adam Williamson <awilliam at redhat.com> wrote:

> 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.
>

That severly limits what maintainers can put out as updates.  
Essentially no version bumps.

--
Jes




More information about the fedora-devel-list mailing list