On 2/21/23 14:01, Fabio Valentini wrote:
On Tue, Feb 21, 2023 at 9:40 AM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
On Mon, Feb 20, 2023 at 10:56:30AM -0800, Gordon Messmer wrote:
On 2023-02-20 10:01, Richard W.M. Jones wrote:
Does it have to be something which looks so much like it might be a
version number? For example it could be helpful for debugging if the
generated requires was something like:
Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1
You mean the literal string "soname", right?
Yes.
I don't know a reason
that wouldn't work off the top of my head, but I also can't think of
a reason that it would add information that wasn't inferred in the
current iteration. One reason we might want to stick with something
that looks like a version is that we might need to extend the system
to allow an epoch in the future (though I really hope that isn't
necessary.)
I mean if I'm looking at an error message, it might help to know that
I should look at the SONAME instead of trying to work out where the
weird version number had come from.
This reminds me, there *is* precedent for stuffing "arbitrary"
versions into RPM Requires / Provides.
Many language ecosystems use virtual Provides / Requires like
"py3dist(foo) = 1.2.3", "crate(foo) = 0.0.11", or even
"golang(github.com/foo/bar/v2) = 2.0.1", where the version is the
*upstream* version (normalized to only contain characters that are
valid in RPM versions), but that doesn't necessarily match version of
the RPM.
The virtual provides that are generated for shared libraries have
always been a bit odd in this regard - maybe we could do something
like "Provides: soname(libnghttp2.so.14()(64bit)) = 14.24.1"?
And that is not "a bit odd"? :D
The ()(64bit) fubar is of course terrible in any form.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
