On 06/22/2009 01:01 PM, 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. I can't think of any fool proof solutions but there are a couple of things that might help: * Run checks on upgrade paths and inform the maintainers when are about to break an upgrade path (ie) before signing it. I noticed a few maintainers I talked to just weren't aware they were doing so and neither were they aware of the %dist.1 trick to workaround the problem atleast in some cases. They might choose to delay an update where it is feasible to do so. Not sure what we can do about security updates or critical bug fixes breaking the upgrade path for the next release. Ideally, the maintainer should have pushed it in sync for the two releases. * In preupgrade, if a user has updates-testing repo enabled, make sure it is enabled for the release they are upgrading to. I think I have a RFE filed on this. This is a bit of a corner case. Rahul Rahul -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
