New subject: rpmlint errors/warnings while reviewing a package

9 Jun 2024

      I'm performing a package review [1] for which I get some rpmlint errors and warnings, but I'm unsure how to proceed...
...
...

rpmlint errors

supernovas-solsys2.x86_64: E: undefined-non-weak-symbol
/usr/lib64/libsolsys2.so.1.0.1 jplint_	(/usr/lib64/libsolsys2.so.1.0.1)
supernovas-solsys2.x86_64: E: undefined-non-weak-symbol
/usr/lib64/libsolsys2.so.1.0.1 jplihp_	(/usr/lib64/libsolsys2.so.1.0.1)
However, the missing `jplint_` and `jplihp_` are an intended feature of the
`solsys2` plugin. As the description of this sub-package implies this plugin
requires user-supplied code to work, and these functions are exactly the
ones that must be defined by the user when using the `libsolsys2` plugin
library. This whole subpackages is aimed for supporting legacy code only,
for people who have existing code that define those `jplint_` and `jplihp_`
symbols, and want to compile their code with supernovas. I can think of 3
ways to address this:

Let it be as such, if that's OK. (The Debian package has passed the

initial reviews and is moving to testing with the same setup.)
 2. I can define weak dummy implementations of the `jplint_` and `jplihp`
symbols that simply return an error. That would cure the rpmlint errors, but
it would also hide the fact that the `solsys2` plugin really requires these
symbols be defined by the user-code. This would probably also mean that I'd
have to create a new upstream branch/tag (e.g. 1.0.1-3) to distinguish it
from the one used by the Debian package.
 3. Drop providing the `solsys2` plugin as a library altogether, and supply
the source code as documentation (examples) only. This is fine, but it
requires a bit of extra work for people who want to link their existing
(old) code with the `solsys2` functionality.
What would be your solution?
I suppose we can ignore those errors, as they are just expected?
...
...

rpmlint warning

supernovas-cio-data.x86_64: W: only-non-binary-in-usr-lib
Is the cio_ra.bin an executable? Or it's just a resource? If the latter,
maybe it can be moved under %{_datadir}/%{name}?
It is a resource but it is a platform-dependent one -- so it has an 'arch'
dependence. %{_datadir} has no arch-dependence, but %{_libdir} does, which
is why I thought this resource might fit there best. Or do you think it's
better to put arch-dependent data into {%_datadir}, perhaps under a
%{name}/%{_isa} directory instead?
I'm not sure here: is it expected that {%_datadir} should not contain arch dependent code? Where it is best to provide such resources?
Thanks
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2283055