Creating an RPM for WeBWorK

Chris Tyler gave us the outline of the procedure for creating an RPM for fedora (and relatives). Similar procedures can probably be followed for ubunutu.  How does the creation of .dmg files for MacOS compare?

Here is the outline:

(1) run rpmdev-setuptree to create ~/rpmbuild and subdirectories

(2) place the source code in ~/rpmbuild/SOURCES

(3) cd ~/rpmbuild/SPECS

(4) create a skeleton spec file: rpmdev-newspec NAMEOFPACKAGE

(5) edit the spec file as appropriate

(6) build the package: rpmbuild -ba *.spec
followed by links to some tutorials:

http://fedoraproject.org/wiki/How_to_create_an_RPM_package

http://fedoraproject.org/wiki/A_Short_RPM_Tutorial

------------------------------------------------

Since we have tarballs on sourceforge  grabbing the WeBWorK files is fairly straightforward.  Because we have been training the WeBWorK community to use svn in order to obtain just-in-time bug fixes, the tarballs have fallen a bit behind the current code base and our rpm will be a bit out of date.  This should not be too bad however since using svn after installing the package will update the code. (It will not however load any new CPAN modules that are required.)

The biggest problem was finding corresponding names for the CPAN modules that are required by WeBWorK.  There is a reasonably up-to-date list in webwork2/bin/check_modules.pl which is used to troubleshoot new webwork installations. 

Replacing :: by -  and  prepending   perl- to the cpan package name worked in most cases to find the fedora package.  Documentation is at http://fedoraproject.org/wiki/Packaging:NamingGuidelines#AddonPerl
The naming scheme will be different in other distros.  Is there a tool for translating package names from one distro to another?

We'll try building this later today on the england.proximity machine.  Preliminary attempts were blocked with errors which we'll try to work through.  One downside to this current procedure seems to be that you'll need half a dozen computers and operating systems to create packages for distribution.  Presumably this could be done on a virtual machine.