avoid defaulting epoch=1 for rpms

[Alexius Ludeman]

hiya,

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?

thanks

lex

[Jordan Sissel]

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.

* If you build a package with the defaults today, you'll get an epoch 1 package, say, epoch 1, version 1.

* If we change the default, in the future, you will build version 2 and get a package with no epoch, version 2.

* When you say "yum install yourpackage" it will see yourpackage (no epoch, version 2) and yourpackage  (epoch 1, version 1), and install the *older* one (epoch 1, version 1).

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.

-Jordan

[Alexius Ludeman]

I've also created issue 381 about this topic.

[Jay Buffington]

It looks like the conclusion on the issue was to go ahead and make no epoch the 

default and to announce it on the mailing list

From https://github.com/jordansissel/fpm/issues/381

    To make 'no epoch' the default, we need to:

    fix the code (easy)

    make as much noise as possible on the fpm mailing list indicating this major change

    make fpm emit a warning of some kind indicating this change, maybe?

 

IMHO, the way you communicate to users that there is a major change between 

releases that is not backwards compatible is to bump the major revision number, 

so the proper thing to do here is to bump the version to 1.0.0.  If I am 

upgrading between major versions I should expect things not to work as they

always have.

BTW, I am +1 for making the default no epoch.  It's the right thing to do.

Jay