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.