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
V Sun, Jun 09, 2024 at 08:35:05AM -0000, Mattia Verga napsal(a):
- 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?
/usr/share is called "share" because it's sharable between architectures. That's why %{_datadir} should not contain architecture specific files.
Those files should go to %{_libdir} if it is a dynamic shared object, i.e. a library, or a plugin), otherwise, there is a catch-all %{_libexecdir} directory for all the other cases, especially for standalone executables.
Another decision factor between %{_libdir} and %{_libexecdir} is whether the file is expected to be installed multiple times for more architectures at the same time (multi-lib). Then %{_libdir} is more suitable because it already embeds the architecture in its path prefix.
-- Petr
packaging@lists.fedoraproject.org
-
Mattia Verga -
Petr Pisar