https://bugzilla.redhat.com/show_bug.cgi?id=1840914 Jerry James <loganjerry@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value --- Comment #2 from Jerry James <loganjerry@xxxxxxxxx> --- Thanks for the review, Erich. (In reply to Erich Eickmeyer from comment #1) > I have found the following (possible) issues: > > - mpsolve-libs.x86_64: E: library-not-linked-against-libc > /usr/lib64/libmps-fortran.so.0.0.1 Yes, that's the fortran interface, and it doesn't need the C library. The resulting shared object doesn't have any unresolved symbols, which is evidence that it really doesn't need libc. > * I'm not 100% sure if this is a false-positive, but it was found by RPM > lint. > - mpsolve.src: E: specfile-error warning: line 141: Possible unexpanded > macro in: Requires: octave(api) = %{octave_api} I'm not sure what to do about this. The octave_api macro is apparently not defined when the source RPM is created. However, it is defined at build time. After doing a Rawhide build, for example: $ rpm -q --requires -p octave-mpsolve-3.1.8-1.fc33.x86_64.rpm ... octave(api) = api-v53 ... So I don't think this is an actual problem. > * Again, not 100% positive on this one here. > - Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in mpsolve- > libs , mpsolve-devel , xmpsolve , python3-mpsolve , octave-mpsolve > * This is a spot where I'm not 100% confident in what's going on here. > From what I can see, there are spots where this is happening? This is kind of a complex package. It probably wasn't fair of me to ask you to review it. There is a library (which is actually the only part I really need), there are command line tools, a GUI, and interfaces to the library from octave and python. All of these have to go into separate subpackages, to manage the dependencies. When a package has both a library and one or more binaries linked to that library, two forms of organization are common: - Make the main package contain the library and a subpackage contain the binaries. You might have a package named libfoo, for example, and the binaries go into libfoo-tools. - Make the main package contain the binaries and a subpackage contain the library. You might have a package named foo, for example, and the library goes into foo-libs. I have chosen the second approach in this case, because the main package name is also the name of one of the binaries, so I thought that would lead to less confusion. This means that everything except mpsolve-libs (and mpsolve-doc) has to depend on mpsolve-libs, rather than on mpsolve, the main package. Look for "Requires: %{name}-libs%{?_isa} = %{version}-%{release}"; you'll find it in the main package, and the devel xmpsolve, python3-mpsolve, and octave-mpsolve subpackages. The mpsolve-doc package doesn't need any dependencies at all, because it is just documentation. If you are going to sign on as the official reviewer here, then up top where it says "Assignee", click on the "take" button. Go to the right of that where it says "Flags", and click on "set flags", then change the fedora-review flag to "?" to mark the review as in progress. You will change that to "+" when you think the package should be approved. At the bottom, find "Status" and change it from "NEW" to "ASSIGNED". If you already knew all this, pardon me for mansplaining. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ 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
