On Jun 24, 2009, at 0:46, Adam Williamson <awilliam@xxxxxxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
