An email discussion regarding this problem: Axel Thimms's original analysis, from an email dated Thu, 29 Jun 2006 07:48:56 +0200 (at <http://tinyurl.com/m2hq6>): Hi, I extracted the FL relevant parts of broken upgrade paths. This is part of an automated mail sent to the fedora-extras list: On Wed, Jun 28, 2006 at 09:10:24AM -0400, buildsys wrote: >> mozilla: >> 3: 37:1.7.13-1.3.1.legacy (FL3-updates) >> 4: 37:1.7.13-1.1.fc4 (FC4-updates) >> 5: 37:1.7.13-1.1.fc5 (FC5-updates) >> 6: 37:1.7.13-1.1.fc5 (FC6) This happend because instead of "fc3" the disttag was chosen to be simply "3" which is rpm-bigger than any "fcX". The only way to fix FL broken paths is to bump the evr of the subsequent releases :/ FL or a spokesman of FL like Jesse need to lobby FC or FE for something like this to happen. Let's hope there will be some new security issue in mozilla 1.7.13 soon ;) -- Axel.Thimm at ATrpms.net Christopher Aillon wrote in <http://tinyurl.com/p3rms>: > David Eisenstein wrote in <http://tinyurl.com/m8xbx>: > >> Hi Chris, >> >> Thought you might wish to be aware of the following for current Fedora >> Core releases... it looks like we in Legacy botched up the upgrade >> path for the current Mozilla product, Mozilla-1.7.13-xxxx. >> >> Might we be able to figure out a way to overcome this? Also-- as we >> in Legacy work on other formerly-core packages, do you, Chris, or you, >> Josh, or any of you on this mailing list have any suggestions on what >> we need to do to coordinate our package naming so we don't botch up >> any future upgrade paths? >> > > I suggest pulling the current package so that nobody else gets it and > replacing it with a package that will not cause these ill effects. > Reducing the effect should be a first step. We'll have to deal with it > somehow, anyway, but I think the current plan of having SeaMonkey > obsolete the mozilla package will work, once that gets done.
Here are the {epoch:name-version-release}s of mozilla packages we (in Fedora Legacy) most recently released: * 37:mozilla-1.7.13-0.73.1.legacy (RH7.3-updates) * 37:mozilla-1.7.13-0.90.1.legacy (RH9-updates) * 37:mozilla-1.7.13-1.1.1.legacy (FC1-updates) * 37:mozilla-1.7.13-1.2.1.legacy (FC2-updates) * 37:mozilla-1.7.13-1.3.1.legacy (FC3-updates) and here are the similar mozilla's most recently released in Fedora Core (from Axel Thimm's note above): * 37:mozilla-1.7.13-1.1.fc4 (FC4-updates) * 37:mozilla-1.7.13-1.1.fc5 (FC5-updates) * 37:mozilla-1.7.13-1.1.fc5 (FC6) It looks therefore like an upgrade from Red Hat Linux 7.3 to Fedora Core 4, 5, or 6 (however unlikely any of those may be) would fail, because RPM or YUM would think that the RHL 7.3 package is actually a higher version than the FC{4,5,6} packages. Is that correct? Chris Aillon suggested that we need to pull our packages out of updates now to fix it on our end, then re-release those packages with updated release numbers. Legacy users who will have already updated their mozilla packages would be out of luck then. My suspicion is that most people who were going to update their Legacy systems with Mozilla would have by now already done so, either automatically using yum or manually. This solution does not seem very user-friendly, as those who already have these packages are still facing the same problem, which would be most of our legacy users if my suspicion is right. Axel Thimm suggested that Legacy needs to get the Core developers to change their naming (or epoch?) of updated packages so upgrade paths won't be broken. I think that would be easiest and most error free for all our users if we could get Core to change their epoch from 37 to 38 with their next release of Mozilla. But would that break something else? Or go against policy or Fedora or Red Hat tradition? My hope is that updated Mozilla-1.7.13/Firefox-1.0.8/Thunderbird-1.0.8 packages will soon be ready for release in Fedora Core. It is also my hope that we can come to some resolution of this that benefits everyone before they are released. Why not increment the epoch in Core? -David
RHL7.3 and RHL9 are fine. The only issues are FC{1,2,3} > FC{4,5,6} If the packages in core are to be touched to get the upgrade paths straight again, then you don't need an epoch bump, which is very ugly and should be kept at a minimum of usage. Starting the Release tag with "2" would already be enough. Removing mozilla from the FL repos and recasting it with a better versioning _below_ the current one will not work. The damage is already done, FL users have upgraded to the "bad" mozilla version and their upgrade paths are broken.
Let's just wait until the next batch of Mozilla updates. Chances are either the version number will get bumped or everyone will move to seamonkey. In either case, the problem will be solved. Of course, we should make sure this won't happen again. FL should release after FC to make sure the upgrade path isn't broken.
Unless I misunderstand something, the problem could also be corrected if FC issued new packages with an rpm-bigger EVR..
Given that our packages are already released, there isn't much we (should) could do on our end. These may be fixed with the switch to seamonkey. FC6 no longer ships mozilla so the problem is mitagated there.