Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
avoid defaulting epoch=1 for rpms #381
[sent this to fpm-users, but putting it here as well]
fpm is defaulting to epoch=1 for RPMs. I found this when upgrading from 0.4.6 to 0.4.29(with some hair pulling to debug). I am working around by using --epoch ''.
I'd like to point out this seems like the wrong default if you read about epoch use, http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html. If I understand correctly they recommend to use epoch only if the package version isn't sort order friendly. (and tell the package provider to read http://semver.org =)
In the next major revision of fpm would it be possible to revert epoch to empty?
(my reply here: https://groups.google.com/d/msg/fpm-users/kJoFKxjQVN8/aHPjYD1bMX0J )The default should probably be nothing, but if we change the default (which we have before), packages folks have built in the past will not work - I can try to explain.
While I agree the default should be 'no epoch' - I think fpm has been shipping with a default epoch of 1 for so long that it would be destructive and hair-tearing for existing users.
So with respect to existing users, we should not change the default even if it is not the 'best' default value.
With respect to new users: New users shouldn't care what the default epoch value is, right? If you're just building packages in a care-free manner (the ideal situation with fpm!), the default values for anything shouldn't bother you much.
I'm still open to changing defaults/etc, but I'll need a strong argument for "default no epoch" that will avoid hurting existing users with previously-built packages.
The hair pulling incident was exactly the bulleted scenario you describe. I had a package such that version=2.0, epoch=None and version=1.0, epoch=1. I had to debug why yum wasn't installing version 2.0...
I completely understand trying to be compatible with existing fpm users. That's what major revision means, it could break compatibility?
OK So here is my proposal -
Let's make the default "no epoch" because I believe that is correct. Correctness is confirmed by the definitions and intentions of the PORTEPOCH, rpm epoch, etc existing for working around version schema changes in the packaged software themselves.
To make 'no epoch' the default, we need to:
referenced this issue
Mar 22, 2013
@jordansissel please don't beat yourself up too much about this, but I just got bitten by the switch to no-epoch. I do believe this is the correct behavior, especially since I've been bitten by Oracle's godawful "RPMs" (yes, with quotes; they're not really RPMs) which have the epoch set to 2000. Somehow, however, upgrading pre-empty-epoch fpm-generated RPMs hasn't been a problem. Maybe it's because I blow away my VMs more often than I upgrade them. :-D Anyway, I don't know how much noise was raised on the mailing list because I'm not on it. Just a data point for you.