Posted by mwr on Wed 30 May 2007 at 06:35
One of my main goals for a managed infrastructure is to make sure I have consistent versions of end-user applications installed everywhere. My users aren't too picky about the version of xemacs installed, but they've got pretty stringent requirements on having a particular version of ANSYS, Abaqus, Fluent, Maple, Matlab, and other large non-free/no-source-available software packages. And they don't all agree on which version should be loaded, so I keep several loaded at once.
Previously, I'd install the software on one candidate system, test it, rsync it to the other systems that needed it, and hopefully put it in the appropriate system image later. And the nightly rsyncs on my dual-boot labs were a pain (can't rsync multiple repositories to one target, so let's have 42 clients simultaneously rsync two NFS-mounted trees to their local disks). So all things considered, it was time to make Debian-style packages of the big, expensive third-party stuff.
Goals (using Matlab as an example):
ch226-21:~/matlab74-7.4.0.287+0.3# ls -F debian/ Makefile src/ ch226-21:~/matlab74-7.4.0.287+0.3# ls -F src/* src/amd64: opt/ usr/ src/i386: opt/ usr/ ch226-21:~/matlab74-7.4.0.287+0.3# ls -F src/amd64/opt/matlab src/amd64/usr/bin/ src/amd64/opt/matlab: 7.4-r2007a/ src/amd64/usr/bin/: matlab74@ mbuild74@ mcc74@ mex74@ ch226-21:~/matlab74-7.4.0.287+0.3#So the src directory contains one folder per Debian architecture this package is available for (goal 5). Each of those architecture folders contains a version-specific software folder under opt. I'm trying to standardize my initial installations to /opt/packagename/version -- many commercial packages, including ANSYS, Abaqus, and Fluent, already default to this style of installation. And so far, the rest of the packages I've worked in will accept this style of installation without complaint. This takes care of part of goal 2 above.
The usr/bin directory contains relative symlinks for the executables people expect to have available. All of these links are tagged with a version. This takes care of goal 3 above.
ch226-21:~/matlab74-7.4.0.287+0.3# ls -l src/amd64/usr/bin/ total 0 lrwxrwxrwx 1 root root 38 2007-05-28 10:31 matlab74 -> ../../opt/matlab/7.4-r2007a/bin/matlab lrwxrwxrwx 1 root root 38 2007-05-28 10:31 mbuild74 -> ../../opt/matlab/7.4-r2007a/bin/mbuild lrwxrwxrwx 1 root root 35 2007-05-28 10:31 mcc74 -> ../../opt/matlab/7.4-r2007a/bin/mcc lrwxrwxrwx 1 root root 35 2007-05-28 10:31 mex74 -> ../../opt/matlab/7.4-r2007a/bin/mex ch226-21:~/matlab74-7.4.0.287+0.3#Now let's look at the top-level Makefile:
build:
@echo "No building required. Binary package."
install:
cp -av src/`dpkg --print-architecture`/* ${DESTDIR}
clean:
@echo "Cleaning not required. Binary package."
Quite possibly the simplest Debian Makefile ever. All we have to do is copy over the desired architecture's directory tree to its proper destination. Now for the contents of the debian directory:
ch226-21:~/matlab74-7.4.0.287+0.3# ls debian/ changelog control dirs postinst README compat copyright docs prerm rules ch226-21:~/matlab74-7.4.0.287+0.3#The changelog and compat files are typical for any Debian package. The copyright file contains the software license agreement from the Mathworks, authors of Matlab. The dirs file contains one entry for /opt/matlab/7.4-r2007a. The docs file is empty. The README file is a simple statement that I repackaged Matlab 7.4-r2007a for the TTU Computer-Aided Engineering Network.
As for the more complicated stuff, rules was generated by dh_make for a single binary package, and I commented out the dh_strip and dh_shlibdeps lines. I tended to get errors with these included. Lots of commercial software doesn't have much in the way of dependencies. About as often, they include a version of a library that conflicts with what's currently installed (libgcc seems to be a common problem lately). Part of my testing is running the software and seeing if there were any missing libraries, so I'll just add those to the control file myself. As for control itself, it's pretty simple:
Source: matlab74 Section: unknown Priority: extra Maintainer: Mike Renfro <renfro@tntech.edu> Build-Depends: debhelper (>= 5) Standards-Version: 3.7.2 Package: matlab74 Architecture: any Depends: libxext6, libxp6, libxt6 Description: MATLAB - The Language of Technical Computing MATLAB is a high-level language and interactive environment that enables you to perform computationally intensive tasks faster than with traditional programming languages such as C, C++, and Fortran. . Packaged for TTU Computer-Aided Engineering Network. Includes the following: . MATLAB, Simulink, Communications Blockset, Communications Toolbox, Control System Toolbox, Distributed Computing Toolbox, Fuzzy Logic Toolbox, Genetic Algorithm and Direct Search Toolbox, Image Processing Toolbox, MATLAB Compiler, Neural Network Toolbox, Optimization Toolbox, Partial Differential Equation Toolbox, Real-Time Workshop, Robust Control Toolbox, Signal Processing Blockset, Signal Processing Toolbox, SimPowerSystems, Simulink Control Design, Stateflow, Statistics Toolbox, Symbolic Math Toolbox, System Identification Toolbox, Wavelet Toolbox.As to the final pieces, postinst and prerm, these both need calls to update-alternatives (Steven Kroon has a good writeup on update-alternatives I worked from). This way, I can have a sensible default version of Matlab available as 'matlab', and let people pick what version they want by specifying it, e.g. 'matlab74' (goal 4 above). For postinst, the configure case has:
configure)
update-alternatives --install \
/usr/bin/matlab matlab /usr/bin/matlab74 300 \
--slave /usr/bin/mbuild mbuild /usr/bin/mbuild74 \
--slave /usr/bin/mcc mcc /usr/bin/mcc74 \
--slave /usr/bin/mex mex /usr/bin/mex74
;;
As for prerm, the primary case has:
remove|upgrade|deconfigure)
update-alternatives --remove matlab /opt/matlab/7.4-r2007a/bin/matlab
;;
And that's it. Running dpkg-buildpackage from the top-level folder makes one ginormous .deb package. I mean seriously large. For Matlab, the .deb files each weigh in at around 800 MB. The source archive is 1.6 GB, expanding out to 2.9 GB. But storing those in one central backed-up location instead of once per backed-up system image is worth it.
Ah, I forgot about goal 1. So far, we've got a package we can run through dpkg -i, but we still need to get it into an apt-compatible repository. That part warrants another post entirely (and if that one's still inaccessible for you, and Steve is ok with it, I'll cross-post it here, too).
This article is reposted from my website, which is apparently inaccessible to some portion of the world.
Fixed.
If you spot any more errors feel free to click the "Edit Article" link on the right hand side.
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ View Weblogs ]
[ Parent ]