Gordon Messmer wrote:
> As there is some discussion of whether the ELF dependency generator
> should use the full version string presented by the library file name's
> suffix, or should assume a SemVer-style major.minor and truncate the
> requirement to the first two dot-separated numbers, questions about
> rpminspect come to mind:
It is generally unsafe to assume the version number to be in any specific
format. While libtool is very strict on the format of soversions, other
build systems that produce versioned libraries are not so strict. E.g.,
CMake allows setting both the soname version and the full version to
basically arbitrary strings. So while you can have a standard libtool-style
versioning:
libfoo.so → libfoo.so.1 → libfoo.so.1.2.3
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
libfoo.so → libfoo.so.1 → libfoo.so.1.bla
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
libfoo.so → libfoo.so.bar → libfoo.so.baz
libfoo.so → libfoo.so.1.2.3 → libfoo.so.42
(In all these, the second one is the soname, the third one is the full name.
The last example could possibly make sense if 1.2.3 is some kind of ABI
version and 42 is some kind of autoincremented SCM revision number. But even
if you think it does not make sense, the build system does not prevent it.)
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).
Kevin Kofler
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
