Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
@rpm-maint: the sole reason for the existence of epoch (and its higher
precedence in the comparison order of {E,V,R}) is to preserve upgradeability
when either upstream has made an inconvenient choice of version, or the
packager/distro has decided to revert to an older version.
This has nothing to do with grievous burdens, and is entirely relevant to the
real world of software distribution where mistakes can and do happen.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400619765___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
It is possible to construct failing counter examples for either obvious choice of missing epoch. Your "strong recollection" cannot be analyzed further. Truly I made the change at the time to simplify what I had to type multiple times a day doing support: Missing epoch is identical to 0 Other answers required multiple interactions to identify exactly what was failing to meet expectations and deal with endless opinions of what SHOULD be done. I believed then (and believe now) that ignoring comparisons with missing values is the superior implementation for missing epoch. I also believe that exposing epoch values everywhere was a poor design choice in yum that has led to brain overload from too much information in the fog of "dependency hell". But what's done is done, discussions be damned. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400611100___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400599202___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
Extreme or not, RPM is expected to deal with missing values (not only optional/missing epoch) sanely and intuitively, you aren't the first to complain. Fix the issue and *SOLVE* the engineering problem(s) instead of 1) claiming that "epoch promotion" doesn't "work" with clear history to the contrary 2) pointing out that distributions are not maintaining upgradeability by changing epochs across major releases 3) suggesting new fangled special case ornamentation like '*' that does whatever you want the comparison to do 4) begging the question by ignoring other similar problems with missing values in EVR all of which has been attempted/suggested in this thread. For the specific case I gave, with all values missing, one could certainly demand that at least one of EVR be present while parsing a dependency. Any comparison system that permis missing values MUST supply sane/natural/intuitive defaults for missing values, or attempt explicit data validation checks to prevent illformed/invalid/indeterminate/unexpected results when comparing. Or we will be discussing the mysterious epoch behaviors for another decade or two. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400381957___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
>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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400365640___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
One last comment on missing values in EVR tuple S ... Whatever scheme is implemented for RPM comparison with missing values, the following pathological dependency with all values missing SHOULD behave naturally: Requires: foo >= :- -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400351755___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
@svpv: good for ROSA, and conversations with me might be partly responsible for
the choice. Using the same epoch when one value is missing has the distinct
advantages (aka "epoch promotion") enumerated below:
1) entirely consistent behavior with what the Debian Borg enclave advocates
2) epoch isn't forever: epoch becomes part of the comparison only when explicit
and automatically is ignored when not present, either because versioning became
"sane" after some hiccup, or because sloppy packaging/packagers has composted
the original reason for an epoch.
OTOH, defaulting a missing epoch to 0 has the following advantages:
1) missing epoch is 0 is trivial to explain doing support
2) returning 0 instead of "not present" eliminates an error that application
developers have forgotten to handle
3) the epoch comparison value returned is less contextually sensitive, all
epoch values are WYSWYG
One can devise extreme/confusing counter example failure cases for either
choices of a default value for a missing element rather easily.
(asides)
What really needs to happen going forward in RPM is to change epoch to a string
from an integer so that the rpmvercmp() comparison is identical for each member
of the {E,V,R} tuple and patterns might reasonably used for epoch as well.
YMMV, everyone's does.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400341017___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400329525___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
Ornamenting epoch values with explicit magic like '*' is irrelevant to this discussion about how a missing epoch in tar = 1.28 should compare to an explicit epoch in tar = 2:1.26. For starters, epoch is a digit string followed by a ':', and '*' is a non-numeric character that pretends at DWIM pattern matching. In fact, '2' would be the saner choice than '*' to solve the tar comparison issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400298924___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400288751___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
You are 15+ years too late to discussions about EVR comparison. Panu wasn't even much of a participant: I was. I summarized the issue above. A choice was necessary between 2 possible schemes for supplying a default value for a missing epoch. I made that choice when I implemented the code. Endless (several year) explanations and discussions resulted, with no obvious consensus forming. Because one of the two obvious choices had already been made, there was only one other alternative choice. I too made that change, to support "A missing epoch is identical to 0". There are no new issues to discuss. Flip flopping between two obvious choices for the default value of a missing epoch every few years cannot please everyone, and in fact will be more harmful than beneficial. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400284644___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400224928___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400216218___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400107061___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
Dependencies are compared sequentially across the set {E,V,R} and 2 .GT. 0
That is what is implemented, and the RPM comparison is working exactly as
expected. That isn't a bug.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399499941___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
> 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`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399394937___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
Well, the fact that e.g. `2:1.26` satisfies `tar >= 1.28` looks like a clear bug to me. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399354721___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
@clime: yes, it makes sense to me, which is why EVR comparison was originally implemented by disabling epoch comparison if one of the values was missing Meanwhile you are (at least) 15 years too late to the discussion to have any chance of succeeding in reverting the behavior. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399250323___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
@Conan-Kudo: linux distributions that do not carry epochs across a distro version boundary also cannot guarantee upgradeability: epochs (with missing == 0) are forever no matter what dain bramage distro's have decided to inflict on their lusers. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399249366___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399163634___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399133045___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
Lets at least get the facts straight. Any comparison system that permits missing values has to supply a default value when a value is missing. There are 2 obvious defaults for a missing epoch in a comparison: 1) use the same, known value, when comparing a missing epoch with a known epoch. This is equivalent to ignoring epochs when missing. 2) make a missing epoch equivalent to 0 Either solution "works" and gives well defined results to EVR comparison. The change was made to treat a missing epoch as 0 was made to simplify explanations demanded by users incapable of determining the meaning of "same" but able to comprehend "zero". -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399124954___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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 no ta 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-399006919___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
`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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-398787595___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
Closed #450. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#event-1691225816___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)
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`? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/450#issuecomment-398759860___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
