V Mon, Feb 20, 2023 at 11:16:24AM -0800, Gordon Messmer napsal(a): > On 2023-02-20 02:06, Petr Pisar wrote: > > I applaud the struggle for ensuring compatibility. However, I worry that it > > will make downgrading RPM packages less feasible. Imagine a user who updates > > a system, finds a regression in a library, attempts to downgrade the library > > and it will result into downgrading later-built reverse dependencies only > > because the library applied a (wrong) fix and the triplet has changed. > > > > Do you know meaning of the numbers? > > > I will say that there are bits that I do not understand: > > https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html > https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html > > The documentation describes a system in which the library indicates the > first interface version it supported, and the latest interface version it > supports, as well as a revision counter that indicates changes in the source > that do not change the interface. I know these documents. However, I'm not sure that this: > As far as I can tell, this manifests in a > file name that ends in ".so.$(current - age).$(age).$(revision)", which > seems like a complicated way to arrive at Semantic Versions. i.e. how a soname and the file names are constructed is true. libtool obviously behaves like that, but it's nowhere documented. I feel that it was an attempt to introduce a versioning schema to enable multiple interfaces (maybe borrowed from Solaris), but it was never fully implemented. One of the consequences is that the age does not reflect in soname and that's the gap you try to fill with your proposal. > I don't know if "current" and "age" appear in the ELF headers. They don't. In ELF headers is only a soname string (scanelf --soname /usr/lib/...). It's an opaque string without any structure. If the library implements symbol versioning, then there are additional version strings. But AFAIK those are always strings. Never comparable versions. > I'm sympathetic to the idea that providing the entire version number is more > strict than is necessary, but I'm not sure under what circumstances it is > safe to provide less. Are there cases where the version number is more or > less than three dot-separated number sequences? First there does not have to any symlinks. Then the symlinks do not have to be substrings of themselves. And finaly those does not have to by dot-delimited, digit-based, or exactly-3 components. However, because ldconfig tool, which maintains ld-config.so's linker cache, imposes some assumptions, in glibc reality those are always dot-delimitted numbers after a soname. Though not always 3 components: lrwxrwxrwx. 1 root root 13 20. led 2022 /usr/lib64/libzip.so.5 -> libzip.so.5.4 -rwxr-xr-x. 1 root root 134392 20. led 2022 /usr/lib64/libzip.so.5.4 lrwxrwxrwx. 1 root root 15 22. led 2022 /usr/lib64/libzmq.so.5 -> libzmq.so.5.2.4 -rwxr-xr-x. 1 root root 648896 22. led 2022 /usr/lib64/libzmq.so.5.2.4 I guess that library files which do not conform to the schema are cached by ldconfig, but never maintained (= recreating symlinks) by ldconfig. > If we always truncate to two, is that the correct thing to do for both > versions with only two numbers and for versions with more than three > numbers? > You need correctly split soname from the version suffix. In the two examples above it's: soname version --------------------- "libzip.so.5" "4" "libzmq.so.5" "2.4" Than if you assume that the version is libtool based, then you can safely handle it as a comparable version string (>= 2.4) and you can safely assume that that second part of the version string ("2.4" -> "4) is a revision not affecting ABI and so you can safely remove it (>= 2). However, all of that are only my assumptions based on observations. One would need to ask glibc and libtool maintainers to confirm that it indeed works like that. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
