I'd like to request that rpmlint adds a warning about deprecated OCaml custom executables. These are easily recognised. The last 12 bytes of the file contain: Caml1999X0[0-9][0-9] (as described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900#74) For example: $ hexdump -C /usr/bin/ocsigen | tail -3 002301a0 43 53 00 00 0f b7 00 00 00 05 43 61 6d 6c 31 39 |CS........Caml19| 002301b0 39 39 58 30 30 38 |99X008| 002301b6 $ hexdump -C /usr/bin/ocamlrpcgen | tail -3 001286c0 52 43 53 00 00 03 6f 44 42 55 47 00 0b 59 0d 00 |RCS...oDBUG..Y..| 001286d0 00 00 06 43 61 6d 6c 31 39 39 39 58 30 30 38 |...Caml1999X008| 001286df (from: http://koji.fedoraproject.org/koji/buildinfo?buildID=61228) $ hexdump -C /usr/bin/coqdep | tail -3 0005d9a0 00 02 c9 00 00 00 05 43 61 6d 6c 31 39 39 39 58 |.......Caml1999X| 0005d9b0 30 30 38 |008| 0005d9b3 (from http://koji.fedoraproject.org/koji/buildinfo?buildID=58696) These should generate a warning saying something like: Executables built with ocamlc -custom are deprecated. Packagers should ask upstream maintainers to build these executables without the -custom option. If you need to include this executables in a package then you must also add a prelink blacklist file in /etc/prelink.conf.d/ so that prelink does not strip this executable. For more information see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900#49
If you want me to generate an actual patch for rpmlint, let me know. I just thought it'd be easier for someone familiar with the code to just add this simple change.
Created attachment 316032 [details] First try Attached is a first try implementation; install it as /usr/share/rpmlint/BinariesCheck.py and let me know how it looks. Example output: coq.x86_64: W: ocaml-mixed-executable /usr/bin/coqdoc Executables built with ocamlc -custom are deprecated. Packagers should ask upstream maintainers to build these executables without the -custom option. If this cannot be changed and the executable needs to be packaged in its current form, make sure that rpmbuild does not strip it during the build, and on setups that use prelink, make sure that prelink does not strip it either, usually by placing a blacklist file in /etc/prelink.conf.d. For more information, see http://bugs.debian.org/256900#49 Note that the unstripped-binary-or-object warning is also printed for these executables. That's probably not a good thing...?
Yes, I've checked that updated file on various ocaml RPMs with and without the mixed executables and it seems to work fine. Two points I would make: (1) The regexp: ocaml_mixed_regex = re.compile('^Caml1999X008$') is probably better as: ocaml_mixed_regex = re.compile('^Caml1999X0\d\d$') since in theory the number at the end might not always be 08. (2) In the link http://bugs.debian.org/256900#49 the '#49' gets stripped off during the redirect by some browsers (eg: Firefox - OK, Safari - strips it, w3m - strips it). So it might be better to link to the complete URL (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900#49) > Note that the unstripped-binary-or-object warning is also printed for these > executables. That's probably not a good thing...? I think that's fine. All OCaml binaries should be stripped except for the few remaining mixed executables.
Ok, checked in upstream with (1) and (2) changed, thanks for the feedback. ((2) really needs some browser bug reports, elinks is affected too, will look into reporting that and w3m.) > > Note that the unstripped-binary-or-object warning is also printed for these > > executables. That's probably not a good thing...? > > I think that's fine. All OCaml binaries should be stripped except > for the few remaining mixed executables. I understand, but I think it'll confuse some people to first get a unstripped-binary-or-object warning strongly suggesting to strip an executable, then in the next warning for the same executable, a strong suggestion to NOT strip it (if it can't be built without ocaml -custom). I'm afraid we'd see some rpmlint bug reports about that :P
(In reply to comment #4) > > > Note that the unstripped-binary-or-object warning is also printed for these > > > executables. That's probably not a good thing...? > > > > I think that's fine. All OCaml binaries should be stripped except > > for the few remaining mixed executables. > > I understand, but I think it'll confuse some people to first get a > unstripped-binary-or-object warning strongly suggesting to strip an executable, > then in the next warning for the same executable, a strong suggestion to NOT > strip it (if it can't be built without ocaml -custom). I'm afraid we'd see > some rpmlint bug reports about that :P OK - I'll leave it up to you.
rpmlint-0.85-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/rpmlint-0.85-1.fc9
rpmlint-0.85-1.fc9 has been pushed to the Fedora 9 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/F9/FEDORA-2008-9125
rpmlint-0.85-2.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.85-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rpmlint-0.85-2.fc10
rpmlint-0.85-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.