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:
>
> 1. 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
--
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
