By and large, current versions of rpmlint have excellent support for OCaml RPMs - thanks. Below are some warnings and errors which rpmlint still emits which either don't seem to represent real errors, or else are errors which cannot reasonably be fixed. only-non-binary-in-usr-lib (example: cduce RPM, bug 241487) In the cduce RPM: /usr/lib/ocaml/cduce/META # text file /usr/lib/ocaml/cduce/cduce_lib.cma # arch-indep bytecode /usr/lib/ocaml/cduce/cduce_lib.cmi # precompiled header file In theory the above files could be shared between arches (but see below). In the cduce-devel RPM: /usr/lib/ocaml/cduce/cduce_lib.a # native code library (code) /usr/lib/ocaml/cduce/cduce_lib.cmxa # native code library (metadata) The OCaml toolchain (particularly ocamlfind) doesn't support splitting these files across several directories. In addition if we did this we'd be incompatible with Debian and every other OCaml distributor out there. So I don't think this idea is going to fly. If these where combined into a single RPM then rpmlint wouldn't emit the warning. But there is a sound OCaml policy reason for the cduce / cduce-devel split. Basically if you're just using the library but not needing to compile native code against the library, you can just install the 'cduce' package. If you want to compile your own code against the library, you normally need both RPMs. ocaml-naming-policy-not-applied (example: cduce RPM, bug 241487) 'cduce' is a standalone language which happens to be written in OCaml and can be included in OCaml. It also includes OCaml libraries. I would say it should be exempted from this rule. One possibility would be to further split the cduce package, eg: ocaml-cduce # bytecode/toplevel library ocaml-cduce-devel # native code library cduce # standalone binary Not knowing how rpmlint implements the policy check, I'm not sure if this is the best thing to do. This error also occurs in the base ocaml package, where it obviously isn't an error. no-binary (example: ocaml-extlib RPM) rpmlint is literally correct here. ocaml-extlib could be noarch and ocaml-extlib-devel should be whatever arch, eg. i386. However there is no way I can tell to express this in an RPM spec file. If I set the whole spec file to noarch, then the subpackage becomes noarch too. configure-without-libdir-spec (example: cduce SRPM, bug 241487) We get this error whenever './configure' isn't one which is generated by autoconf, and thus wouldn't understand the --libdir parameter. (Actually this isn't an OCaml-specific problem, but I imagine it would apply to lots of packages).
First, thanks for a detailed bug report, but in the future, please report each issue in a separate bug so they're easier to track. > only-non-binary-in-usr-lib (example: cduce RPM, bug 241487) Should be fixed in upstream svn: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1402 Not tested with a binary cduce package because I could not find one and building it requires some packages that aren't (yet) in Rawhide at the moment. > ocaml-naming-policy-not-applied (example: cduce RPM, bug 241487) I think a valid way to approach this warning would be to just ignore it. We can of course add special cases in rpmlint's shipped config, but I'd rather not go there. If you disagree, feel free to submit a config patch :) > This error also occurs in the base ocaml package, where it > obviously isn't an error. Fixed upstream: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1399 > no-binary (example: ocaml-extlib RPM) Not sure what to do about this. Ideas? > configure-without-libdir-spec (example: cduce SRPM, bug 241487) Downgraded into a warning and info message improved upstream: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1403
>> only-non-binary-in-usr-lib (example: cduce RPM, bug 241487) > > Should be fixed in upstream svn: > http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1402 > > Not tested with a binary cduce package because I could not find one and building > it requires some packages that aren't (yet) in Rawhide at the moment. If you have Rawhide, then the following package also gives this error: ocaml-xml-light-2.2.cvs20070817-6.fc9.<arch>.rpm $ rpmlint ocaml-xml-light-2.2.cvs20070817-6.fc9.i386.rpm ocaml-xml-light.i386: E: no-binary ocaml-xml-light.i386: E: only-non-binary-in-usr-lib The change in cset 1402 looks fine to me though. >> no-binary (example: ocaml-extlib RPM) > > Not sure what to do about this. Ideas? I don't know. I was just pointing it out really. Thanks for fixing these, I'll close this bug now.
(In reply to comment #2) > > $ rpmlint ocaml-xml-light-2.2.cvs20070817-6.fc9.i386.rpm > ocaml-xml-light.i386: E: no-binary > ocaml-xml-light.i386: E: only-non-binary-in-usr-lib Yep, I tested with some other ocaml packages and it seemed to work fine. Retested now with ocaml-xml-light and the upstream svn version now only emits the no-binary error as expected. > Thanks for fixing these, I'll close this bug now. Thanks, but I'd rather keep it open until a fixed package is available in Fedora so I remember to add bug number pointers to the package changelog, and in case others run into these same issues they can find this bug more easily.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
rpmlint-0.83-1.fc9 has been submitted as an update for Fedora 9
rpmlint-0.83-1.fc8 has been submitted as an update for Fedora 8
rpmlint-0.83-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rpmlint'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5185
rpmlint-0.83-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
rpmlint-0.83-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.