Bug 197422 - Current Fedora Legacy mozilla-1.7.13 packages break upgrade path to Fedora Core releases 4,5,6
Summary: Current Fedora Legacy mozilla-1.7.13 packages break upgrade path to Fedora Co...
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: mozilla (Show other bugs)
(Show other bugs)
Version: unspecified
Hardware: All Linux
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact: Ben Levenson
URL: http://www.redhat.com/archives/fedora...
Whiteboard: LEGACY, 1, 2, 3, discuss
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-01 07:13 UTC by David Eisenstein
Modified: 2013-01-10 03:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-13 14:01:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Eisenstein 2006-07-01 07:13:27 UTC
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>):


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@fedoraproject.org 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.

Comment 1 David Eisenstein 2006-07-01 08:23:05 UTC
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

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?


Comment 2 Axel Thimm 2006-07-01 08:50:07 UTC
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.

Comment 3 Marc Deslauriers 2006-07-02 00:26:34 UTC
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.

Comment 4 Pekka Savola 2006-07-03 07:03:34 UTC
Unless I misunderstand something, the problem could also be corrected if FC
issued new packages with an rpm-bigger EVR.. 

Comment 5 Jesse Keating 2006-08-13 14:01:23 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.