@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
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
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
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
>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.
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
@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
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
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
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
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.
> 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
> 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:
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:
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
> 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
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:
@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
@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
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
> 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
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
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...
`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
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
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:
26 matches
Mail list logo
