Some RPM packages intentionally set the 'epoch' field in their SPEC file to work around issues in version detection or to give it special hints.
You can see how many of your installed packages actually use the epoch field like this:
That'd mean there is only one package that has the epoch set at the moment, the other 406 have set it to None/Null/0.
Which one has the epoch "2000" - this is easiest to find like this:
So this means someone thinks Java was created 2000 seconds after our calendar starts. Interesting.
My actual issue was slightly different - all agent packages of Rudder had the same epoch, causing a little problem where you could not update the agent.
The solution was to use "rpmrebuild" to modify the package. I generated a replacement package from the existing one.
First: Get rpmrebuild!
Once downloaded, we create a working directory where re-packaged RPMs get stored
The package is properly signed and the great moment here was finding the noarch RPM which worked flawless on my SLES system.
And this is how I used it to make a new package:
First we view the current epoch of the input package
one with the epoch reset, and then one more that has it to just a "newer" date than the original one:
here you can see the two changed files and the original:
Now if you want to modify something else, the official rpmrebuild documentation can be found here:
What a wonderful little piece of software!