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-sysv126.96.36.199.0)
They could use a better "interactive tool" for doing mass installs; the nearest "common" thing thus far is AutoRPM, which can do things such as mirroring RPMs from an FTP site, keeping installed RPMs consistent with an FTP site or local directory, and keeping installed RPMs in a cluster or network of systems consistent.
Some people get their noses terribly bent out of joint at the thought of using RPM to manage software on their behalf; they would much rather do so by hand.
rpm2cpio is a short Perl script that takes an RPM file and strips off the thin veneer that separates it from being a cpio archive.
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.
apt is a package "selection" tool used in conjunction with dpkg for the Debian project. apt is used as a systemto query available packages (perhaps from multiple locations), allowthe user to select a set of packages that are desired, and then verifies that dependancies are being satisfied.
Efforts are ongoing to come up with improved interactive tools to replace dselect; experimentation is ongoing, with Aptitude being the most satisfactory alternative at this point.
The Debian tool apt does not forcibly need to be tied to dpkg; it could be used with other package manager tools such as RPM , albeit with the caveat that apt expects some functionality not yet provided by RPM. This project seeks to try this out, and perhaps fill some of the functionality holes.
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.
NSBD is an automated Web-based distribution system that is designed for distributing free software on the internet, where users cannot trust the network and cannot entirely trust the maintainers of software. NSBD authenticates packages with Pretty Good(Tm) Privacy (PGP(Tm)) digital signatures so users can be assured that packages have not been tampered with, and it limits the maintainer to only update selected files and directories onthe user's computer. NSBD's focus is on security, leaving as much control as is practical in the users' hands.
To accomplish the automated updates, NSBD supplies a means of checking for updates to packages and automatically downloading and installing the updates. This "automated pull" style of distribution has the same effect as the "push" style of distribution that is being given press lately, but gives more control to the user. A direct "push" style is also supported which is not used as frequently but which is especially appropriate for situations where there are multiple contributors to a shared server (for example, a shared web-page server).
Yet another system to organize Unix-based software where"packages" are assembled in a set of organized directories. Symbolic links are then used to "deploy" the software into the desired location.
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.
A software packaging system intended to allow programs to be installed, without OS-dependent changes, on as many platforms as possible. It was originally based on BSD Ports, and runs on such platforms as:
Many Linux distributions
Others such as IBM AIX, Apple OS-X, Darwin, BeOS, BSDi should be coming soon...
Yggdrasil is 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:
An extensive network of RPM files contributed to RedHat...
This alternative to Red Hat's Glint utility uses NCURSES, thus running on a terminal rather than as a pure X app.
Encap is a package manager that may be used to manage local software packages being installed in some "local" directory structure. It places, by default, packages in version-named directories in /usr/local/src and then links files as needed into other parts of /usr/local. It uses autoconf to allow packages to (at least potentially) be system-independent. It seems to rather parallel BSD Ports.
Essentially amounts to a way to build installable "tarballs" for Linux-based systems...
GNUpdate is an open source,
universal package management system. What does this mean? Well for
starters, it will allow RedHat users
to install debian packages, Debian users to install RedHat packages, and so on. It does this
libpackman library, which provides
a single API for accessing multiple package formats and package
databases. GNUpdate provides its own
package database, composed entirely of RDF ( XML Resource Description
Format). However, this does not prevent users from continuing to use
their existing package database. The RDF database is accessed via the
libgnurdf library, which provides an easy way to open, create, modify,
and search RDF files.
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