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:
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.
> 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:
>> only-non-binary-in-usr-lib (example: cduce RPM, bug 241487)
> Should be fixed in upstream svn:
> 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:
$ 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:
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.