[3544] in SIPB_Linux_Development
Re: update failure from fresh install
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Sep 3 14:07:30 2001
Message-Id: <200109031807.OAA13400@egyptian-gods.MIT.EDU>
To: Angie Kelic <sly@MIT.EDU>
cc: linux-dev@MIT.EDU
In-Reply-To: Your message of "Mon, 03 Sep 2001 11:21:09 EDT."
<200109031521.LAA01251@fighting-falcon.mit.edu>
Date: Mon, 03 Sep 2001 14:07:27 -0400
From: Greg Hudson <ghudson@MIT.EDU>
> Makes me wonder what the '3' is for -- there are other things in the
> control list with numbers after them:
Ah, you win. The "3" is an epoch number. I'll explain.
An RPM revision (my term; RPM doesn't have a word for this) has three
components: an epoch, a version, and a release. The version and
release show up in the canonical RPM filename, but the epoch does not.
Since the epoch is the most significant component of the revision, you
can think of it as the invisible hand of the the Versioning God ("thou
shalt be considered newer than perl 5.00503, even though 5.6.0 would
normally compare less than 5.00503 because 6 is less than 503").
/bin/rpm normally looks at the header of an RPM to determine its
revision. rpmupdate, the Athena progam used by update_ws, deduces the
revision from the filename, since examining headers would be
prohibitively expensive for the RPMs in AFS. Since the filename does
not contain an epoch, the release list puts that information in a
second field after the filename.
When Jonathon proposed a method for creating the initial release list,
he either didn't know about or didn't remember epoch numbers, and I
didn't think of them when I okayed it.
So, when rpmupdate tries to go directly to 9.0.0, what it thinks is:
The old release list had 0:1.7-0.6.x
The locally installed version is 3:1.7-0.6.x
The new release list has nothing
Since it looks to rpmupdate like ypbind has been locally upgraded, no
action is taken for that RPM (locally upgraded RPMs are only touch if
the release has an even newer version).
On the other hand, if you update to 8.4.26 first, you have no problem
with ypbind (since updating athena-afs and athena-krb5 has nothing to
do with ypbind) and now you have a real release list with an epoch
number for ypbind, so the update to 9.0 can go smoothly.
The fix is for the SIPB installer to put epoch numbers in the
generated rpm list. See /mit/ghudson/scripts/rpmepoch for a clue
on how to do that.
