New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

avoid defaulting epoch=1 for rpms #381

Closed
lexinator opened this Issue Mar 13, 2013 · 15 comments

Comments

Projects
None yet
6 participants
@lexinator

lexinator commented Mar 13, 2013

[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?

thanks
lex

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Mar 13, 2013

(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.

  • 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.

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Mar 13, 2013

You mentioned a hair-pulling incident. What was the problem caused by having epoch as 1?

@lexinator

This comment has been minimized.

lexinator commented Mar 14, 2013

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?

@koendc

This comment has been minimized.

koendc commented Mar 18, 2013

So, for now you can use '--epoch 0' to have the 'default' epoch number.

@lexinator

This comment has been minimized.

lexinator commented Mar 18, 2013

as i said in my first comment the work around is to use --epoch ''. epoch shouldn't be set as default.

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Mar 21, 2013

hhmm...

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:

  • 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?
@lexinator

This comment has been minimized.

lexinator commented Mar 21, 2013

+1

@blalor

This comment has been minimized.

blalor commented Apr 24, 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.

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Apr 24, 2013

yeah, sorry that you got bit by it!

fpm warns you when you don't set an epoch, but that's not awesome and really I don't think there was any kind of good path to the 'correct' behavior.

Thanks for the note :)

remh added a commit to DataDog/dd-agent that referenced this issue Jan 22, 2014

remh added a commit to DataDog/dd-agent that referenced this issue Jan 23, 2014

prof-milki pushed a commit to prof-milki/xpm that referenced this issue Dec 18, 2014

jls
Merge pull request jordansissel#388 from r4um/fix_381
Closes jordansissel#381 rpm, epoch should not be set by default.

prof-milki pushed a commit to prof-milki/xpm that referenced this issue Dec 27, 2014

Merge pull request jordansissel#388 from r4um/fix_381
Closes jordansissel#381 rpm, epoch should not be set by default.

jordansissel added a commit that referenced this issue Apr 24, 2015

Merge pull request #388 from r4um/fix_381
Closes #381 rpm, epoch should not be set by default.
@brendanlong

This comment has been minimized.

brendanlong commented Dec 3, 2015

Is there a way to make the warning go away?

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Dec 7, 2015

@brendanlong we could add a flag for it, maybe?

@brendanlong

This comment has been minimized.

brendanlong commented Dec 7, 2015

That would work. It's just annoying to be "warned" that nothing is wrong every time, especially if you integrate fpm into scripts.

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Dec 7, 2015

Agreed. Maybe since the warning was added 2+ years ago as part of a way to help notify users of the behavior change --- maybe it'd be fine to remove it?

I'm somewhat in favor now of removing the warning.

@lexinator

This comment has been minimized.

lexinator commented Dec 9, 2015

+1 on removing the warning.

@josephfrazier

This comment has been minimized.

Contributor

josephfrazier commented Dec 23, 2015

+1 on removing the warning, or providing a flag to silence it

josephfrazier added a commit to josephfrazier/fpm that referenced this issue Dec 24, 2015

jordansissel added a commit that referenced this issue Jun 20, 2016

Merge pull request #388 from r4um/fix_381
Closes #381 rpm, epoch should not be set by default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment