On Sun, 11 Nov 2018, Michael Schroeder wrote:
> Or we keep the disttag out of the EVR comparison, like proposed by @wladmis.
> I believe this is much saner.
Yes, since we don't know about practical uses of comparing the disttags
w.r.t. a linear order (when treating < or > in Requires), it looks nice
not to implement now something that is not needed.
In ALT, they are unordered alternative values.
However, from ALT's point of view and ALT's practice, conceptually, there
is a kind of package dependency which can be satisfied only if another
package's disttag is equal to the value specified in this dependency. So,
order is not used, but equality is. Of course, precedence doesn't matter
in this case, but a limited comparison is actually what happens here
conceptually.
Now it is implemented with a "hack": rpmbuild tranlates the disttag into
an additional Provides of a special form. (The corresponding Requires can
also only be added by rpm-build internally, not in the spec-file by a
human.)
Here is an example:
$ rpm -q librpm7 --qf='%{DISTTAG}\n'
sisyphus.214147.300
$ rpm -q librpm7 --provides | tail -2
.sisyphus.214147.300.3.1-librpm7-4.13.0.1-alt4
librpm7 = 4.13.0.1-alt4
$ rpm -q rpm --requires | fgrep librpm
.sisyphus.214147.300.3.1-librpm7-4.13.0.1-alt4
$
If the comparison mechanism used to check the dependencies would be more
flexible, no special "hacks" would be needed, making the code more clear,
probably. It's an information to keep in mind for RPM developers when
thinking about this issue.
(In ALT, there is also another kind of special dependency value
(set:XXXX), which behaves as a partial order, not a linear order.[1]
[1]:
https://github.com/rpm-software-management/rpm/issues/362#issuecomment-345475643
"set-versions"
So, extending the upstream comparison mechanism to more than just a linear
order defined lexicographically on top of the linear orders of individual
components of EVR is something that would make sense for us. Answering
the question about the precedence of a new component in the existing
definition of the order doesn't make much sense for us IMO.)
--
Best regards,
Ivan
--
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/589#issuecomment-437682327_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
