Am 2017-11-26 15:26, schrieb wf...@niif.hu:
At least I can't see any other way to express alternative groups of library dependencies like ((libnss and libnspr) or libssl), which would be needed for crypto plugins.
Well, if a software wants to support alternatives, then the following would work quite well: - Software has an internal abstraction layer for these libraries. (It will need that anyway.) - Any integration with any of these libraries is done in plugins for that specific software (which are dlopen()d). The plugins themselves expose only the abstraction layer, but are in turn linked against the actual libraries. Since the internal plugin interface between the software and the various plugins for different libraries is something that the authors of the software themselves control, there's never going to be an issue there, you upgrade them in lock-step and everything just works. And since the plugin libraries themselves are directly linked against the actual libraries, automatic dependency generation will just work, as well as symbol versioning. In Debian packaging you'd ideally want to separate out each alternative into their own package, so that the main package doesn't need to depend on all alternatives. Regards, Christian
