search

ibm-s390-linux / s390-tools

Tools for use with the s390 Linux kernel and device drivers
MIT License
63 stars 60 forks source link

ELF binary ap-check in /etc is not conform with FHS #143

Closed frank-heimes closed 2 years ago

frank-heimes commented 2 years ago

Hello, the commit: https://github.com/ibm-s390-linux/s390-tools/commit/2da206f5a6b3e0340027910a67dc48d8d9c83020 introduces the ELF binary 'ap-check' and places it in folder '/etc/mdevctl.d/scripts.d/callouts/'. But according to the Filesystem Hierarchy Standard https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSystemConfiguration Refer to Section 3.7 ELF binaries are forbidden in /etc. Based on this lintian (the static analysis tool for Debian packages) indicates this as 'binary-in-etc' error (and I assume rpmlint similarly).

A workaround (that I use for now) is to move the 'ap-check' binary within the build tree to /usr/lib/s390-tools/ - where other binaries files already reside, and instead place a wrapper with the same name at /etc/mdevctl.d/scripts.d/callouts/' that looks like this: --------%<----------------%<----------------%<----------------%<-------- --- /dev/null +++ b/etc/mdevctl.d/scripts.d/callouts/ap-check.sh @@ -0,0 +1,4 @@ +#!/bin/sh +# wrapper script for 'ap-check' binary, to avoid lintian error 'binary-in-etc' + +[ -e /usr/lib/s390-tools/ap-check ] && /usr/lib/s390-tools/ap-check "$@" --------%<----------------%<----------------%<----------------%<--------

Since I'm doing this partially with the help of debian helper (package management) files (debian/rules and debian/s390-tools.install), I unfortunately have no PR that could be directly picked up.

hoeppnerj commented 2 years ago

Duplicate of #139

hoeppnerj commented 2 years ago

There was also an issue opened against mdevctl: https://github.com/mdevctl/mdevctl/issues/63

frank-heimes commented 2 years ago

Sorry for not having properly check the other open issues. I think an mdevctl upstream solution would be best, hence I'll subscribe to mdevctl/mdevctl#63 too. As of now, such a wrapper script can be (an is for us) a valid and FHS conform short term workaround.