On Fri, May 22, 2020 at 07:48:53PM -0500, Parker Gibson wrote: > The issue I see is that no package management system I know of handles > multiple so versions, they explicitly state packages conflict with > each-other even if in principle the so versioning means they would not. Gentoo portage when updating a package that changes a soname of a library installs the new package, but keeps the old library in the file system and remembers the reverse dependencies of the old library. Once all reverse dependencies are updates/rebuilt to use the new library, the old library is deleted from the file system. Of course this is only a partial workaround because the old and new libraries can expect different (e.g. configuration) files and than the old library could malfunction. But in reality it almost never happen and the reverse dependencies are rebuilt sooner than somebody notices it. > Some repositories can handle multiple major so versions and I do think this > may provide enough flexibility. I suppose the place of ultimate conflict is > the devel packages as multi-version headers would always be in conflict, and > I can’t imagine the nonsense one would have to go through to tell > autoconf/pkg-config “no wait I want this specific version” in a shared > library environment. Why not? If an ELF executable can request a specific library version, then a build system could request the specific header or pkg-config files. Wrapping everything (a library and the headers) into a dedicated directory only papers out the real problem. The fact that nobody was bodered to implement a versioning into pkg-config files only shows that always building against the latest version is good enough. Technically a library can version pkg-config files on the name level (foo-1.pc, foo-2.pc) and projects that undergo a major API change do that. At the end if a library changes API, then the library user must be patched. Thus changing foo-1 into foo-2 in the user's code is the least problem. > But in principle there is nothing FHS related limiting multiple versions of > a library. It’s an artificial limitation that probably helps ease the lives > of package maintainers, it is not a technical limitation imposed by FHS. Yes. E.g. DNF could keep more package versions installed (provided they do not conflict). It probably does not happen because the gains do not outweigh the expenses. -- 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
