handling of the EKMF Web plugin and library

[sharkcz]

s390-tools 2.15.0 have added EKMF Web plugin and support library to the set of produced libs and tools. But they don't follow the best practices on how they can be properly distributed.

• plugins like zkey-ekmfweb.so should live in $libdir/$project so they can be distinguished from regular shared libraries and not interfere with automatic dependency generators
• both plugins and libraries should set soname to inform about the ABI they provide, you already use the symbol version script when linking them
• libekmfweb should use libekmfweb.so.1 as its filename (tied to the soname) and make libekmfweb.so the development symlink. I assume there is a reason for having this library as shared, because you are installing ekmfweb.h so you are expecting other users than zkey

You can take a look at the qclib, they also use plain Makefile to manage all details of the building/linking process.

[sharkcz]

also libekmfweb and the zkey-ekmfweb plugin should go under /usr/lib64 rather than /lib64

[ifranzki]

Thanks for suggesting this.
I have prepared a patch to introduce what you asked for.
Please take a look and let me know if this is what you are looking for:
ifranzki@b27e3ec

I moved zkey-ekmfweb.so to /usr/lib64/zkey/. To ensure that zkey can load this plugin I needed to specify the absolute path to the library in zkey/kms-plugins.conf. Is there a better way for this?

[sharkcz]

Thanks, Ingo. I have commented in the patch itself.

[ifranzki]

Thanks for the comments. I have reworked the commit according to your comments and force pushed, please see here: ifranzki@d09ed47.

So for zkey-ekmfweb.so I only create the .so without a version in the file names, but I set the soname ELF attribute to zkey-ekmfweb.so.1, is this correct?

[sharkcz]

Thanks for the comments. I have reworked the commit according to your comments and force pushed, please see here: ifranzki@d09ed47.

thanks, will take a look

So for zkey-ekmfweb.so I only create the .so without a version in the file names, but I set the soname ELF attribute to zkey-ekmfweb.so.1, is this correct?

yes, I would do it this way. It will contain the ABI info, but still allow simple dlopen()ing via zkey-ekmfweb.so.

[sharkcz]

I have commented in the new patch, I believe it should be the last batch :-) I have applied the changes locally and the result looks good.

[ifranzki]

Thanks, I have adjusted the commit accordingly:
ifranzki@4a1979d

We will integrate this patch internally and make it available on the master branch soon.

[sharkcz]

Awesome, I will add the last version to the Fedora s390utils package.

[ifranzki]

Would moving zkey-ekmfweb.so to /usr/libexec/zkey/ be fine with you, too?

[sharkcz]

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir is what our guidelines say about libexec, thus I would prefer to keep zkey-ekmfweb.so in /usr/lib64/zkey.

[xnox]

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir is what our guidelines say about libexec, thus I would prefer to keep zkey-ekmfweb.so in /usr/lib64/zkey.

yes.... it says that libexecdir may be used..... which would be the same location for both Ubuntu and Fedora. Ubuntu cannot use /usr/lib64/zkey at all for the s390x port.

also it is cute that the fedora guidelines mention upstream configuration system.... it would be nice if s390-tools had meson (or make / autoconf, or well anything) to detect and configure these things. As by default rpm macros and debhelper do pass all of these paths with the right expected locations, to buildsystems that have configure step.