TUGboat, Volume 26 (2005), No. 1 17 Using the RPM package manager for (LA)TEX packages Tristan Miller Abstract RPM is a package management system which pro- vides a uniform, automated way for users to install, upgrade, and uninstall programs. Because RPM is the default software distribution format for many operating systems (particularly GNU/Linux), users may find it useful to manage their library of TEX- related packages using RPM. This article explains how to produce RPM files for TEX software, either for personal use or for public distribution. We also explain how a (LA)TEX user can find, install, and re- move TEX-related RPM packages. 1 Background 1.1 The evolution of package management systems In the first decade or two of personal computing, most software was distributed on and run directly from floppy disks. Users lucky enough to have a hard drive could copy the contents of these floppies into a directory on their hard disk and run it from there. When a user wanted to delete the program, he had to remember which directory he had copied it to, find it in his file system, and manually delete it, taking care to first preserve any data files he had created. As programs and hard disk capacities grew in size, software was increasingly distributed on multi- ple floppy disks or (later) on a CD-ROM. Vendors would provide tools — usually simple shell scripts — to automate the process of creating a directory on the hard drive, copying the contents of each floppy to it, configuring the installed copy of the program, and then finally deleting it when the user requested that it be uninstalled. These tools grew in sophistication along with the underlying operating systems (OSes), which by the 1990s had begun to provide standard hardware drivers and graphical interface toolkits for third- party software to use. Now software installation pro- grams could not merely copy themselves to the hard drive; they also had to search for the presence and lo- cation of requisite system and third-party software, register themselves with the OS so that they too could be found by other programs, and create icons for the user in the system menu or desktop. Some of the better installers would also do sanity checks such as making sure the user didn’t install two copies 18 TUGboat, Volume 26 (2005), No. 1 of the same software package, or automatically de- Fortunately, until such time as the TEX commu- tecting and upgrading older installed versions of the nity develops and settles on its own package manage- software. With the advent of dial-up bulletin board ment standard, users can avail themselves of their systems and eventually home Internet access, it be- operating system’s native package management sys- came important for software to be downloadable in tem for the maintenance of TEX packages.1 In this a single file rather than as dozens or hundreds of article, we describe how to do this using the RPM individual files as was the case with physical media. Package Manager, a packaging system originally de- Because each vendor wrote its own installation veloped by Red Hat and now in widespread use on program, users often found themselves confused by several operating systems. different interfaces and lacking a single tool with which to install, upgrade, and remove software. To 1.3 RPM versus other package managers remedy this, each operating system developed its RPM has a number of good features to recommend own standard software package management tool to itself to TEX package management. Most impor- be used by all users and vendors. Software devel- tant is its portability — RPM enjoys the status of opers can now distribute their programs in specially being the official package format specified by the prepared packages containing the source code and/ Linux Standard Base [4], meaning that any LSB- or binary executables for the software along with compliant GNU/Linux distribution can handle RPM important metadata such as the software’s name, packages. Distributions which use RPM by default version number, vendor, and dependencies on other include Aurox, Fedora Core, Lycoris, Mandriva (for- software. Packages might also include checksums merly Mandrake), PCLinuxOS, PLD, Red Flag, Red or cryptographic signatures which the package man- Hat, and SUSE. Distributions which use a different agement system can use to verify that they were not native package format but which can handle RPM corrupted or tampered with during distribution. by virtue of their LSB compliance include Debian, Users install and remove these packages using MEPIS, Slackware, and Ubuntu. standard system software, which keeps a database However, RPM is by no means limited to GNU/ of all installed packages and makes sure that all de- Linux operating systems. The RPM tools have been pendencies are met — for example, by automatically ported to Mac OS X, Novell Netware, and some com- fetching prerequisite packages, or warning the user if mercial Unixes. Because the tools and file format he is about to remove a package that other installed specifications are released under a free license, it is software depends on. possible to reimplement them on virtually any oper- ating system. In fact, some work has already gone 1.2 Package management and TEX into porting RPM to Microsoft Windows, with some Unfortunately for fans of quality typesetting, TEX rudimentary tools available now. and friends are currently stuck in the Dark Ages of It bears mention, however, that there are many software package management. Though TEX distri- alternatives to RPM the user may wish to consider. butions now mostly conform to the TEX Directory At least one TEX distribution, MiKTEX for MS- Structure [8], which specifies standard locations for Windows, provides its own packaging utility, mpm the installation of certain types of files, there is cur- [6, §§3.2 and A.9], which has much the same func- rently no standard package format or associated tool tionality as RPM. However, mpm works only with for installing, upgrading, and removing macro pack- the MiKTEX distribution, and moreover is a net- ages, styles, classes, scripts, fonts, documentation, work tool which fetches packages from some central and other TEX-related paraphernalia available on repository. As far as the present author is able to CTAN and elsewhere. determine, it is not possible for package authors to As a result, users who download new packages create and distribute their own MikTEX packages. must themselves check for prerequisites, manually Another alternative is to use your operating process .ins and .dtx files, create the appropri- system’s native package management system. In ate directories in their texmf tree, copy the files in, many cases, this requires purchasing the system’s of- and perform necessary post-installation configura- ficial software development kit (SDK). (In the case tion (such as running texhash). Worse yet, when a user wishes to uninstall a package, he must manu- 1 In this document “TEX” refers to the entire TEX sys- ally remove the files, often from multiple directories. tem, including LATEX, METAFONT, BibTEX, and other com- This usually entails consulting the original package ponents. Similarly, a “TEX package” here means any set of installation instructions to help remember what got related files distributed, installed, and maintained as a unit. This meaning includes but is not limited to LATEX 2ε pack- installed where. ages, which are style files supplementing a document class. TUGboat, Volume 26 (2005), No. 1 19 of Microsoft Windows, this SDK can be downloaded gnomovision- 1.2 - 273 . i586 .rpm for free, though it requires a gigabyte of hard drive | {z } |{z} |{z} | {z } space and comes with a restrictive license.) Another package name version release architecture disadvantage is that the distributed packages are of- ten bundled as executable files, adding considerable Figure 1: A sample RPM filename overhead (possibly several megabytes) to the size of the package. (Consider that most T X packages are E users who want to avoid the hassle of manual pack- only a few kilobytes in size.) Users may also be wary age management. This section assumes that you of running executables for fear of viruses or spyware have a basic familiarity with downloading and man- which the packager may have deliberately or unwit- ually installing T X packages. tingly included. E Finally, §4 briefly touches on some advanced Users of Mac OS X will be pleased to note that topics for RPM packagers and distributors. there exists an unofficial package management sys- 2 tem, i-Installer, which enjoys notable popularity 2 RPM basics among T X users on the Mac. The author of this E 2.1 RPM files and where to find them tool provides i-Installer packages, or i-Packages, for a number of TEX packages. Furthermore, the i- Software for use with RPM is distributed in files Installer distribution includes tools for users to cre- known as RPM packages, which have the filename ate their own i-Packages. suffix .rpm. In order to distinguish between dif- ferent versions of a package, a standard file nam- 1.4 About this article ing scheme is employed which encodes the package This article makes liberal use of illustrative exam- name, its version and release number, and the com- ples to help the reader understand how to use the puter architecture it is designed to work with. The RPM packaging tools. To help distinguish between syntax is illustrated with an example in Figure 1. various types of computer input and output, we em- • The package name indicates the name of the ploy the following typographical conventions: software (or in our case, TEX package) packaged • When depicting an interactive shell session, any in the RPM.