On 2023-02-21 20:19, Kevin Kofler via devel wrote:
It is generally unsafe to assume the version number to be in any specific format.
I'm not sure if that means that you are opposed to the proposal, or to the idea of truncating the version numbers, or something else entirely. :)
you can also have things such as: libfoo.so → libfoo.so.1 → libfoo.so.1.2 libfoo.so → libfoo.so.1 → libfoo.so.1.2.3.4
Seems good so far, that should be compatible with the proposal.
libfoo.so → libfoo.so.1 → libfoo.so.1.bla
The current implementation will only generate a versioned dependency if the suffix is numbers separated by dots, so this library would be compatible in that it would be ignored (since we don't know the semantics of non-numeric versions.)
but even things such as: libfoo.so → libfoo.so.1 → libfoo.so.4.5.6 libfoo.so → libfoo.so.4 → libfoo.so.1.2.3
That's surprising, but as long as the version in the full name increases monotonically, those should work as well.
libfoo.so → libfoo.so.1.2.3 → libfoo.so.42
Hm... the current implementation wouldn't generate anything in this case because the full name's version doesn't have a dot separating numbers, and my naive expectation was that such a case probably meant that only a "major" version was present and that it'd match the soname, in which case versioning the dependency wouldn't add any information that wasn't already there. Perhaps the right thing to do instead would be to produce a versioned dependency if the suffixes do not match.
The full version (or even the soversion, for that matter) is also not guaranteed to be monotonic in any way. E.g., you could have: libfoo.so → libfoo.so.1 → libfoo.so.1.deadbeef or even just: libfoo.so → libfoo.so.1 → libfoo.so.deadbeef where "deadbeef" is a non-monotonic SCM hash (e.g., a git hash).
Right... as above, those would remain unversioned. _______________________________________________ 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
