I have decided to make an RPM for codelite since there isn’t one on the Fedora repositories. The source tarball contains a .spec file, however rpmlint produces a bunch of errors and warnings on the resulting .rpm and so I started from scratch.
Having built this package manually already, I knew what the pre-requisites were. These are also listed in the *.tar.gz/BuildInfo.txt. See my previous post, for more information on compiling manually.
The rpm built successfully after making the necessary modifications to the %files directive and all that was left was rpmlint-ing the resulting package and .spec file.
I got a bunch of warnings and errors but the most cryptic was:
codelite.i386: W: unstripped-binary-or-object /usr/lib/codelite/*.so
This was repeated for every object and binary produced by make. Usually if you tell rpmlint to be more informative using the -i switch: rpmlint -i *.rpm, you can follow the instructions or clues to fix each error/warning. In this case the -i switch had no information for that message-id and Google produced no answers. I found a Common Rpmlint Issues page on the Fedora wiki, but there was nothing about “unstripped objects”. I talked to someone on #fedora-devel@Freenode and they pointed me to the strip utility.
I narrowed the *.so and binary objects to 3 strip lines and added them to the %install section as follows:
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
strip -s -v %{buildroot}%{_bindir}/%{name}{,_indexer,_cppcheck}
strip -s -v %{buildroot}%{_libdir}/%{name}/*.so
strip -s -v %{buildroot}%{_libdir}/%{name}/debuggers/*.so
Make sure you add the strip lines after your rm -rf and make commands or the stripping will fail.
I also got a bunch of devel-file-in-non-devel-package messages from rpmlint, but these were aimed at a templates/* folder. They seemed to be example projects and thus not-critical (I should do further testing to ensure they are actually non-critical).
One error I got was the world-writable message on codelite-icons.zip in %{_datadir}/codelite/. The vendor configure script explicitly set the permissions to 0666 on this file. This was interesting because it means that they were either careless when capturing files for the configure script’s initial creation, or the application actually needs access to modify this zip file under non-privileged user context. The latter is more likely, however it seems like a bad design choice as this could cause conflicts between users’ distinct working environments.
There were also a backup files (files that end in ~) left behind in the templates/* folder prompting rpmlint to give backup-file-in-package error messages. If you want to remove all these files from your install add this to %install section of your .spec file:
$ find %{buildroot}%/ -type f -name "*~" -exec rm -rf ’{}’ \;
I, however decided to do away with this problematic templates directory by preventing the Makefile script from copying it during its install phase. To do this I had to modify the original configure script and comment out the appropriate lines (see attached .patch file).
Since modifying the vendor/upstream tarball is against best practices, the only way to do this is to create a patch and let rpmbuild take care of the modifications on the fly.
$ diff -u configure configure.fixed > ~/rpmbuild/SOURCES/codelite-2.7.0.4375-configure_fix.patch
The patch should be unique so as to not conflict with current or future patches. The next step is to modify the .spec file telling it to make the necessary modifications before %configure creates the Makefile:
...
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Patch0: %{name}-%{version}-configure_fix.patch
...
%prep
%setup -q
%patch0
%build
%configure
%patch0 is a macro for the patch command and therefore accepts the usual switches such as -pN (where N is the number of directories to strip from the file being patched, see manpage). I had created the patch in the same directory as the original configure (after %setup happens the working directory is %{_builddir}).
After all this rpmlint was pretty clean. The only outstanding warning was no-manual-page-for-binary, and since the vendor tarball did not contain any manpages, I can safely ignore this.
P.S.: If rpmlint complains about not having a dictionary for en_US (enchant-dictionary-not-found) install aspell and aspell-en.
