[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Jun 24, 2009, at 0:46, Adam Williamson <awilliam 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:


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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]