If you’re running RedHat or a Linux distribution based on RedHat, chances are you’ve had occassion to use RPMs. RPMs and Red Hat’s accompanying package management system (and other systems like it) greatly simplify the task of maintaining the software on a system. With RPMs, installs, upgrades, and even downgrades are quick and easy.
If you’re running RedHat or a Linux distribution based on RedHat, chances are you’ve had occassion to use RPMs. RPMs and Red Hat’s accompanying package management system (and other systems like it) greatly simplify the task of maintaining the software on a system. With RPMs, installs, upgrades, and even downgrades are quick and easy.
Because RPMs make installations uniform and simple, most open source projects are distributed as RPMs (as well as other forms of packages). With a little effort, you can distribute your code and binaries as RPMs as well. You need some new tools to build RPMs, but they’re relatively easy to master. This month, let’s review the basics of package management and outline the process of creating your own RPMs.
A Brief History
A software package is a collection of related files, ranging from the typical collection of binaries and man pages, to full-blown, expansive software development kits (SDKs) that includes tools, libraries, documentation, and source code.
Before the advent of formal package formats and package managers, people typically archived and distributed software in a tarball — a tar file or a compressed variant of a tar file — and installed software by extracting tarballs on their systems. While useful, the simplicity of a tarball is also its Achilles’ heel: a tarball is just an inert collection of files, and once extracted, there’s no way to match an installed file to its tarball (or to other related files) or reconstitute…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
