https://bugzilla.redhat.com/show_bug.cgi?id=2283055 --- Comment #35 from Attila Kovacs <attipaci@xxxxxxxxx> --- (In reply to Mattia Verga from comment #33) Hi again Mattia, Before I upload a new SPEC (and a new SRPM built from it on Copr), I wanted to get your opinions on the issues you brought up. > A few issues while reviewing the package: > > - Sources in the SRPM does not match with those downloaded from the upstream > URL This must have been me referencing the wrong Copr build, since the SRPM is built on Copr from the source, and so the only way they can diverge is if the build was an older one, from before the last change on upstream. It does bring up a question of versioning though, which I wanted to clarify before proceeding. The upstream version is a tag on a branch that contains patches to make packaging easier, as per your earlier suggestion. It has an upstream version number '1.0.1-2'. As such, would the RPM version be '1.0.1' (and release '2'), or would it be '1.0.1-2' and the release whatever Fedora assigns, so the RPM may have a version number such as '1.0.1-2-1'? (I feel the latter is the more appropriate, but I'd like you to confirm). > - No known owner of /usr/lib64/supernovas > Perhaps the -cio-data subpackage should just own the entire > %{_libdir}/%{name} directory? Ye, that makes sense. I'll add a '%dir %{libdir}/%{name}' into %files for it... > - Macros in: supernovas (description) > I think this error is due to the presence of a '%' character in the > description. It should be escaped (I think using a double '%%') I think I removed these macros a while back (I don't see them in the spec any more). This is another indication that the Copr build I referenced last was an old one by mistake... > - rpmlint errors > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol > /usr/lib64/libsolsys2.so.1.0.1 novas_trace (/usr/lib64/libsolsys2.so.1.0.1) > 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 novas_error (/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) OK, this is a bit more involved... The latest spec (and upstream branch from which the package is built) fixes 2 of the 4 errors. The `solsys2` library just needed a link flag against the parent `libsupernovas` to get two of the missing symbols defined. 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? > - 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'll await your responses before submitting a new SPEC with the appropriate changes. Thanks in advance, -- Attila. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2283055 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202283055%23c35 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
