I started with a stock RH beta3 system on which I'd custom-compiled and installed grip-2.96-1.i686.rpm a couple of days ago. Today, I ran up2date for the first time. It pulled down a list of RPMs from Red Hat to update, one of which was grip-2.96-1.i386.rpm. Somehow, it didn't recognize that this grip was already installed, perhaps because of the different targets for which the installed grip and the updated grip RPMs were built.... grip should not have even been on the list of available updates.
Assigned to the owner of component
All of our gnome related packages have an epoch set, so if you have a version of grip without an epoch, it will assume out version is newer. I'll take a look at the logic for computing updates to make sure that it doesnt attempt to install packages in this scenario.
Out of curiosity, what's an epoch?
In laymen's terms (as those are really the only ones that I know!) epochs allow us to specify that a specific package is actually newer than another package. And just as I learned in school, an example always makes things better. Take the case of package ypbind . . . it went from version 3.3 to version 1.7. In order to tell RPM that ypbind-1.7 was actually newer than ypbind-3.3, we add an epoch to ypbind-1.7. When RPM evaluates ypbind-1.7, it sees that it has an epoch (like '1') and then looks at ypbind-3.3, sees that it has no epoch and is able to know that ypbind-1.7 is "newer" then ypbind-3.3 and therefore should replace/upgrade it. That's pretty much it.
Thanks! All that makes sense. So, how do I work with these, see these, etc? I'm looking at rpm -qi output from an up2date beta3 machine on ypbind and not seeing it, and there's no mention of "epoch" in the rpm man pages.
They are set in the specfile . . . the easiest way to see them is to use one of the querytags. So, something like "rpm -q ypbind --queryformat "%{NAME}-%{VERSION}-%{RELEASE}-%{EPOCH}\n"