On Tue, 10 May 2022 12:48:23 +0200, Florian Weimer wrote: > * Neal H. Walfield: > > On Tue, 10 May 2022 12:04:52 +0200, > > Florian Weimer wrote: > >> * Neal H. Walfield: > >> > >> > There are two major constraints. Because rpm's OpenPGP API is public, > >> > it must be preserved until the next soname bump. And, the OpenPGP > >> > backend should be pluggable. > >> > >> How is this plug-in mechanism supposed to work? Via RPM configuration > >> files? > > > > It is a build-time configuration option. When you configure rpm, you > > can do: > > > > ./configure --with-crypto=sequoia > > > > to get the Sequoia backend. --with-crypto defaults to libgcrypt, > > which uses the internal OpenPGP implementation with libgcrypt. (There > > is also --with-crypto=openssl, which uses the internal OpenPGP > > implementation with OpenSSL.) > > That's a very limited form of pluggability.
True. > I expect the most portable approach (for ELF targets) is to use a stub > shared object that contains all symbols, including those provided by > dependencies. (librpmio.so should probably be a linker script > referencing the actual object, to prevent accidental loading of > librpmio.so via dlopen.) That approach keeps the run-time DT_NEEDED > value an implementation detail. > > I don't know if libtool supports that out of the box. > > On non-ELF targets, you may need forwarder functions, and the plug-in > library cannot use the same symbols. Thanks for the ideas. Panu also suggested forwarder functions. That indeed sounds like the least troublesome from a portability and robustness perspective. Thanks, :) Neal
