Linux has provided a fair degree of innovation in the area of "system configuration" and in particularly in terms of providing tools to more easily manage the installation, configuration, and (when needed) deinstallation and/or upgrade of "packages" of software.
The point of the exercise is to improve on traditional "tarballs" where no information is automatically tracked.
Packages are typically comprised of:
Information about the package, including such things as its name, the identity of the author, information on who maintains the packaged version of the software, versions, and dependancies.
Software used to do any preparation of the package for readiness; this might include installation scripts, configuration scripts, maintenance scripts, and de-installation scripts
Information to prove identity; cryptographic signatures for other components to help protect from an adversary modifying the payload along the way.
The "body" of software and data in the package.
Notable package managers include:
RPM has such notable features as:
Tracking the files for each software package
Tracks documentation for packages
Bundles sources along with patches and control files, allowing easy rebuilding of software for multiple architectures.
One design goal was to allow use of "pristine" (e.g. original) sources. Source code from the primary source is bundled along with any patches required to make it compile in the RedHat environment. This concept came from the authors of the (4) BOGUS distribution of Linux.
PGP signatures, providing verification that the package came from a source you can (hopefully) trust;
Dependencies, where a package may indicate that it requires files from other packages (with specific versions) in order to function.
Relocating packages to where you want them installed
Allowing non-root users to install packages (presumably in safe fashion and location)
Permits use of further layers of package management tools such as Red Hat's "GLINT" package and the likes
Runs on a goodly variety of platforms, including:
Linux - Sparc/Intel/powerPC/Alpha/m68k/SGI
Solaris - Sparc/Intel
Hewlett-Packard HP-UX 10.20
SCO OpenServer 5.0.2
Digital UNIX 3.2/4.0
On recent versions such as 5.1, rpm is actually included by IBM in a default AIX install.
NCR v2.02 (i486-ncr-sysv18.104.22.168.0)
This is a project founded by the Development Team from Cable & Wireless Deutschland's Application Services division. The goal is the creation and maintainance of portable and easy to install software packages for use on the major Unix server platforms. Currently Solaris, Linux and FreeBSD are officially and fully supported. Additionally, NetBSD, OpenBSD, and Compaq Tru64 are unofficially and/or partly supported.
The underlying packaging technology is based on the RedHat Package Manager RPM, version 4. Nevertheless this project is completely self-contained and does not even need a preinstallation of RPM. Instead, RPM is provided as an OpenPKG RPM package itself plus a tricky bootstrapping procedure in order to allow one to create from scratch the initial state of the whole OpenPKG software packaging system.
One thing that is particularly interesting about OpenPKG is that it is apparently an independent reimplementation of RPM . It is not simply a "hacked up" version.
Debian has also released a powerful tool called dselect for which Red Hat does not have a near equivalent. dselect collects togetherlists of packages that are available to be installed via various methods (e.g. - on a CD-ROM, on a local disk, accessable via NFS, or accessable via HTTP ) and provides an integrated list from which an administrator may select applications to be installed. dselect has an arguably unfriendly user interface, but nonetheless does an admirable job of managing lists of packages to do automated system upgrades.
Utility to permit debian packages to be configured in an automated fashion (e.g. - without the need for human intervention), with the plan of having varied data sources such as SQL databases ...
alien can convert between rpm, dpkg, and Slackware's tgz formats.
The FreeBSD has a similar concept that they call Ports.
Find a source for the source code in classic "tarball" form (e.g. - archived into a file using TAR, and then compressed using GZIP ) for a particular piece of software.
The "tarball" is successively searched for in various places, from "most local" (e.g. on a local disk, perhaps a CD-ROM containing FreeBSD software) and then on to more remote locations, such as a FreeBSD FTP Archive site, or perhaps even the"source" site where the author of the software places the latest editions.
The "tarball" is then extracted, and checksums verified to ensure that it has been received correctly.
If any patches are required, the "Ports Makefile"causes them to be applied.
This would trivially include adjusting compiler options in the package's own Makefile to conform with FreeBSD needs.
The "Ports Makefile" then causes the package to be built from source, and optionally installed.
It appears that some sort of database is maintained containing information on:
Port "packages" that have been installed, with names and version numbers, and
Possibly (not entirely clear to me) information on what specific files were installed.
Yggdrasil was working on a system that puts some of the common functionality of file tracking systems in a common software layer that can track installation of files by any method, provided that thesoftware that implements it is linked against the standard shared GNUC library. This is done by trapping the system calls that modify files. This way, one may track installation of files installed by rpm, debian dpkg, stampede, tar files, or even doing makeinstall from a source tree.
Under this scheme, the Red Hat tools would be aware of all of the rpm components installed on the system, the Debian tools would be aware of all of the dpkg components installed on the system, and the Yggdrasil tools would be aware of everything. This would be a big step forward for GNU/Linux users, but, clearly, it would be even better if all of the tools could see all of the software.
Efforts in this direction with regard to the current RPM central database format have led to a separate program with a very simple interface that will probably be of general use to current RPM users. So, we are releasing a test version of this separate program in its current form, in the hopes of getting good technical advice and contributed improvements.
Thus, for instance, one might collect a "package" up as the tarball frobnicator-5.3.bin.tar.gz, installing it via:# cat frobnicator-5.3.bin.tar.gz | (cd / ; tar xfvzp - )
Information concerning the frobnicator package could then be loaded into the RPM database via:# tar tfvz frobnicator-5.3.bin.tar.gz | \ modify_rpmdb --name=frobnicator --version=5.3 \ --mode=replace
Here are a variety of related links:
This alternative to Red Hat's Glint utility uses NCURSES, thus running on a terminal rather than as a pure X app.
Essentially amounts to a way to build installable "tarballs" for Linux-based systems...
RERO stands for Release Early, Release Often, and is a system designed to help automate release management with a view to allowing software releases to be done early and often.
Swbis is a project to implement an Open Source, vendor-neutral software administration system for Unix and GNU/Linux platforms. Mostly based on POSIX software installation tool standards.
If this was useful, let others know by an Affero rating