version comparison with epoch does not work as expected

[clime]

I have just hit this problem where for my package in my spec file, I have:

Requires: tar >= 1.28

which on EPEL7 currently gets satisfied by already installed tar 2:1.26. The thing is that I really need tar 1.28 or higher because of --exclude-vcs-ignores feature that was added in 1.28. A newer version of tar with the required feature is available in my enabled copr but it does not get installed from there because rpm says 2:1.26 is enough to satisfy tar >= 1.28.

[mlschroe]

That's not a bug, no epoch means epoch zero and 2 > 0. So it does work as expected.

Can't you use Requires: tar >= 2:1.28?

[clime]

Requires: tar >= 2:1.28 would work for me right now because the tar package I built has version 2:1.30-3. But that seems rather accidental.

The problem here is that if tar packager resets the epoch to zero at some point the Requires: tar >= 2:1.28 will suddenly become impossible to satisfy and my package will there become impossible to install.

If I put Requires: tar >= 2:1.28 into the specfile, I will need to carefully watch what's going on with the tar package so that I change the condition in my specfile at the right time.

This is really not something I would willingly want to do. When I put Requires: tar >= 1.28 into the specfile, I am talking about tar 1.28 that is provided through rpm because I depend on a certain feature introduced in that version. The epoch should not really matter and certainly the condition should not get satisfied by tar 2:1.26.

Therefore, I am quite positive this is a bug. I understand your explanation about no epoch meaning zero but at the same time, I would like to challenge this at least in the context of version comparison because it does not produce a convenient behavior for a packager, nor for an upstream developer who maintains his/her own spec file.

[pmatilai]

It used to be different in the early days of rpm. That behavior, known as epoch promotion, does not work and it was changed for very good reasons in the early 2000-something. So not a bug, and not going to change either, no epoch == zero epoch is the only workable interpretation. Been there...

Note that your worry about tar dropping the epoch is a needless one: epochs can never be dropped. Doing so would be a severe packaging bug in tar.

[Conan-Kudo]

Note that your worry about tar dropping the epoch is a needless one: epochs can never be dropped. Doing so would be a severe packaging bug in tar.

Strictly speaking, this is not true. There are Linux distributions that make it a policy to not carry Epochs forward across releases. openSUSE and (soon) OpenMandriva are examples of distributions with this policy.

[clime]

Hey Jeff,

So there are two things, right? First, you can say that when Epoch tag is not used, then Epoch tag's value is zero for a package.

If rpm needs to compare two packages, which one is newer, then it can do full-fleged comparison with epochs included.

If however comparing a package version (that always contains an epoch number) against a custom version expresion, which does not include an epoch number in it, it can just skip comparing the epochs.

So, yes, missing Epoch tag implicates Epoch = 0 for a package.

But missing epoch in a version expression means: "do not compare epochs".

Does it make sense to you?

The thing is that i would like to get spec files to be used directly by upstream and if they really needed to care about an epoch being set somewhere e.g. in Fedora, that just makes the whole thing...well, not possible. It's like this epoch algo really separates the whole rpm ecosystem into individual clusters. Could we, please, consider it again whether the behavior really can't be tweaked?

[clime]

Well, the fact that e.g. 2:1.26 satisfies tar >= 1.28 looks like a clear bug to me.

[clime]

Well, the fact that e.g. 2:1.26 satisfies tar >= 1.28 looks like a clear bug to me.

I should also say why. That's because tar 2:1.26 contains a completely different code than tar 1.28. Requires: tar >= 1.28 is there because the codebase up from 1.28 is required to run the package correctly. It should not be possible to satisfy that requirement with tar version less than 1.28.

[clime]

Yes, you are right the {E,V,R} compare sequence is alright but the 0: auto-prepending isn't.

I think that for the next major RPM release this change could be discussed.

[pmatilai]

I think that for the next major RPM release this change could be discussed.

No. And that should be the end of that, thank you.

[clime]

No. And that should be the end of that, thank you.

While I value your point of view a lot, you haven't provided any arguments. Also it's not very useful to cut something down immediately without discussing it first. You might be right but you also might not be right. I understand you went through this before but that's not really an argument if this is a beneficial change to be made, which I believe it is. So, please, let's give it some space and time. I don't think this needs to be immediately rejected or accepted. If you have links to the previous discussions, that would help as well to save some time.

[ignatenkobrain]

I think one of main issues would be different behavior between upgrading packages vs comparing versions. While I agree that current behavior is not intuitive for many, we have what we have. One of options might be adding some notation (using star instead of numerical epoch?) to indicate that it shouldn't take it into account. --

…

-Igor Gnatenko

[svpv]

BTW, in a Mandriva-based Russian distro, they switched back to the "promote the serial" logic which was also effective in rpm-4.0. Ostensibly it makes more sense, with which I tend to concur. Binding to an upstream version is a powerful and self-sufficient concept, so it makes every sense to require e.g. ffmpeg >= 4.0. As opposed to this, the serial number is an ill-devised concept which in this case also breaks the promise that the supplicant actually gets ffmpeg >= 4.0.

[clime]

Whatever scheme is implemented for RPM comparison with missing values, the following pathological dependency with all values missing SHOULD behave naturally:

Requires: foo >= :-

That seems to be really an extreme case.

[rpm-maint]

If a package requires ffmpeg >= 4.0, this is probably because some feature is implemented in ffmpeg starting with the upstream version 4.0. And this is just about the only valid reason for such a dependency to exist. Now, if the serial is not promoted, the packager has to look up the serial number and write something like ffmpeg >= 2:4.0. I believe this is called burdening people, as Jesus said, with grievous burdens which are hard to bear. Upstream versions are relevant, because their features are advertised. Package serials are obscure and irrelevant. Also note that the serial number is a moving target, so the dependency such as ffmpeg >= 2:4.0 might never be enough, it will easily succumb to e.g. 3:3.3. There is no hard promise!

[pmatilai]

While I hardly present in any discussions leading to the change back then, I do remember dealing with it from the other side of things in the plentiful, namely from apt-rpm and packaging POV. I'm really not going to dig back into them old memories in detail, but I have a fairly strong recollection of there being some unsolvable (corner or not) cases with epoch promotion that the current behavior solves. Which is what I meant with the "doesn't work" remark. But of course it's possible I'm misremembering something there, been a while...

For your amusement, https://www.redhat.com/archives/rpm-list/2003-June/msg00141.html