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"? Fabio _______________________________________________ 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
