Greetings,
I am trying to make a Fedora compliant rpm package and I have found myself in need of guidance.
The software I am trying to package contains a test suite that compiles a few c files at build time.
When installing with a prefix, the test suite and examples are installed in ${PREFIX}/share/doc/charliecloud/test and ${PREFIX}/share/doc/charliecloud/examples respectively. The spec file uses the standard %{_prefix} macro, thus the test suite installs to /usr/share/, which is reserved for architecture-independent files. The presence of the compiled test suite and example binaries causes rpmlint to complain with 'arch- dependent-file-in-usr-share' errors (among others).
Any guidance or advice is greatly appreciated.
Note I am an upstream developer of this software and we would prefer to keep the contents of the test suite and examples together. Where they should be located for compliance with Fedora and the FHS is a little unclear to me (/usr/libexec ?).
Finally, note that I am new to rpm packaging (this is my first spec file...) and this community. Forgive me if the scope or content of this message is inappropriate or malformed for this forum.
Spec file: https://github.com/hpc/charliecloud/blob/epel-package/packaging/epel-7/0.9.6...
rpmlint output (non-verbose and pruned, i.e., removed errors and warnings not relevant to this discussion):
charliecloud.x86_64: E: arch-dependent-file-in-usr-share /usr/share/doc/charliecloud/test/sotest/sotest charliecloud.x86_64: E: arch-dependent-file-in-usr-share /usr/share/doc/charliecloud/examples/syscalls/userns charliecloud.x86_64: E: arch-dependent-file-in-usr-share /usr/share/doc/charliecloud/examples/syscalls/pivot_root charliecloud.x86_64: E: arch-dependent-file-in-usr-share /usr/share/doc/charliecloud/test/sotest/bin/sotest charliecloud.x86_64: E: arch-dependent-file-in-usr-share /usr/share/doc/charliecloud/test/sotest/lib/libsotest.so.1.0 charliecloud.x86_64: E: no-ldconfig-symlink /usr/share/doc/charliecloud/test/sotest/lib/libsotest.so.1.0 charliecloud.x86_64: E: arch-dependent-file-in-usr-share /usr/share/doc/charliecloud/test/sotest/libsotest.so.1.0 charliecloud.x86_64: W: dangling-relative-symlink /usr/share/doc/charliecloud/test/bin ../../../../bin charliecloud.x86_64: W: spurious-executable-perm /usr/share/doc/charliecloud/test/sotest/sotest charliecloud.x86_64: W: spurious-executable-perm /usr/share/doc/charliecloud/examples/syscalls/userns charliecloud.x86_64: W: spurious-executable-perm /usr/share/doc/charliecloud/examples/syscalls/pivot_root charliecloud.x86_64: W: spurious-executable-perm /usr/share/doc/charliecloud/test/sotest/bin/sotest charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/Build.missing /bin/bash charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/chtest/Build /bin/bash charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/chtest/fs_perms.py /usr/bin/env charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/chtest/signal_out.py /usr/bin/env charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/chtest/dev_proc_sys.py /usr/bin/env charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/make-auto /usr/bin/env charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/make-perms-test /usr/bin/env charliecloud.x86_64: W: doc-file-dependency /usr/share/doc/charliecloud/test/chtest/bind_priv.py /usr/bin/env
On 09. 01. 19 0:53, Jordan Ogas wrote:
Greetings,
I am trying to make a Fedora compliant rpm package and I have found myself in need of guidance.
The software I am trying to package contains a test suite that compiles a few c files at build time.
When installing with a prefix, the test suite and examples are installed in ${PREFIX}/share/doc/charliecloud/test and ${PREFIX}/share/doc/charliecloud/examples respectively. The spec file uses the standard %{_prefix} macro, thus the test suite installs to /usr/share/, which is reserved for architecture-independent files. The presence of the compiled test suite and example binaries causes rpmlint to complain with 'arch- dependent-file-in-usr-share' errors (among others).
Any guidance or advice is greatly appreciated.
In case you just want to provide the example/test sources, they can live there.
The compiled binaries however should not.
If you want to provide a way to run the tests by the user without compiling, I suggest libexec or even bindir (with appropriate name) would do.
The primary question would be: why are those files shipped. Would users experimenting with those probably read the source and compile them, or just execute them?
On 1/9/2019 12:49 AM, Miro Hrončok wrote:
On 09. 01. 19 0:53, Jordan Ogas wrote:
Greetings,
I am trying to make a Fedora compliant rpm package and I have found myself in need of guidance.
The software I am trying to package contains a test suite that compiles a few c files at build time.
When installing with a prefix, the test suite and examples are installed in ${PREFIX}/share/doc/charliecloud/test and ${PREFIX}/share/doc/charliecloud/examples respectively. The spec file uses the standard %{_prefix} macro, thus the test suite installs to /usr/share/, which is reserved for architecture-independent files. The presence of the compiled test suite and example binaries causes rpmlint to complain with 'arch- dependent-file-in-usr-share' errors (among others).
Any guidance or advice is greatly appreciated.
In case you just want to provide the example/test sources, they can live there.
The compiled binaries however should not.
If you want to provide a way to run the tests by the user without compiling, I suggest libexec or even bindir (with appropriate name) would do.
The primary question would be: why are those files shipped. Would users experimenting with those probably read the source and compile them, or just execute them?
The feature/bug of _libexec, of course, is that it's not in anyone's PATH. If these files are likely to be used by some specific subset of users, but not by others and of no real core need, another option is to move the binaries to _bindir at %install create a dedicated subpackage for them and any associated example configs for those tests, named something like charliecloud-utils or charliecloud-tests
-jc
Thank you Miro, I appreciate that you took time to respond.
If you want to provide a way to run the tests by the user without compiling, I suggest libexec or even bindir (with appropriate name) would do.
We would like users to be able to run the test suite without compiling. It seems like placing the test and example directories in libexec/charliecloud may be a reasonable approach.
Question: is this something I could handle in the spec file, e.g., move the test suite directories as part of the %install section of the spec file? It would be simple enough to update the master Makefile, I am just curious.
The primary question would be: why are those files shipped. Would users experimenting with those probably read the source and compile them, or just execute them?
The test suite c files are compiled and used to test a subset of key features. For example, pivot_root.c walks through the dance of Linux namespace and pivot_root(2) syscalls that result in an unprivileged container. Each step is commented in detail so that users who are interested in how our unprivileged containers work can follow the logic in the example source files.
Since we compile them at build-time, I suppose if we wanted to include these c files we could place them in /usr/share/doc/charliecloud.
"JO" == Jordan Ogas jogas@lanl.gov writes:
JO> We would like users to be able to run the test suite without JO> compiling. It seems like placing the test and example directories in JO> libexec/charliecloud may be a reasonable approach.
I'd suggest not doing that. If you expect someone to run it, put it somewhere where they can run it. That location would be /usr/bin, with data in /usr/share or %_libdir as appropriate. You probably also want it in a subpackage ("foo-tests" is a commonly used naming convention) so that users don't have to install it if they don't want it.
I recall there was some issue where there was a desire to keep the files together in some fashion. One common method of doing this is using a subdirectory of %_libdir (so /usr/lib64/whateverpackage) and then creating stub executables or symlinks in /usr/bin. For example, both chromium and libreoffice do this.
Interestingly, dnf has taken the odd step of putting executables in /usr/libexec and symlinking them into /usr/bin, which I personally find quite bizarre
JO> Question: is this something I could handle in the spec file, e.g., JO> move the test suite directories as part of the %install section of JO> the spec file?
Well, if you want anything to end up in the final generated RPM files then you must place them somewhere under %buildroot in the %install section, and then reference them in the %files section. Whether it's the projects build infrastructure which installs them or just some calls to cp is completely dependent on the software in question.
- J<
I'd suggest not doing that. If you expect someone to run it, put it somewhere where they can run it. That location would be /usr/bin, with data in /usr/share or %_libdir as appropriate. You probably also want it in a subpackage ("foo-tests" is a commonly used naming convention) so that users don't have to install it if they don't want it.
We ended up moving forward this approach; thank you :-).
Well, if you want anything to end up in the final generated RPM files then you must place them somewhere under %buildroot in the %install section, and then reference them in the %files section. Whether it's the projects build infrastructure which installs them or just some calls to cp is completely dependent on the software in question.
- J<
We were able to move the relevant example and test directories as needed via %install. I have learned a lot and I am appreciate of the responsiveness from the community. I still need guidance regarding a pesky 'dangling symlink' error, however, since it is unrelated to FHS or test suite placement, I will start a separate conversation. Again, thank you.
packaging@lists.fedoraproject.org
-
Japheth Cleaver -
Jason L Tibbitts III -
Jordan Ogas -
Miro Hrončok