5:53 p.m.
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....
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
2:49 a.m.
New subject: Guidance request: rpmlint, FHS, and test suite location
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:08 p.m.
New subject: Guidance request: rpmlint, FHS, and test suite location
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
10:42 a.m.
New subject: Guidance request: rpmlint, FHS, and test suite location
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.
11:50 a.m.
New subject: Guidance request: rpmlint, FHS, and test suite location
>>>> "JO" == Jordan Ogas <jogas(a)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<
4:09 p.m.
New subject: Guidance request: rpmlint, FHS, and test suite location
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.
1917
days inactive
1927
days old
packaging@lists.fedoraproject.org
5 comments
4 participants
participants (4)
-
Japheth Cleaver -
Jason L Tibbitts III -
Jordan Ogas -
Miro Hrončok