Basic Package Management Features

Both RPM and Debian packages rely on a database of information about installed packages for normal operation. This database includes the names of all installed files, checksum information on those files, the names and version numbers of the packages to which they belong, and the other packages upon which each package depends. This database is invaluable in managing software. For instance, suppose you want to install the manydep package. When you try to do so, the utilities note that manydep depends on several other packages, such as minorlib, obscurelib, and bizarrefonts. Without these packages, manydep won't function correctly, so if they aren't installed on your system, the package utilities complain and refuse to install manydep. If you install all of these packages and then try to uninstall minorlib, the system notes that manydep depends on minorlib, and so won't uninstall the latter package. Fitting with the Linux philosophy that people are smarter than computers, you can override the tool's refusal to perform an operation because of failed dependencies. You might do this if you've installed the package in some way that's not reflected in the package management database. Particularly in the case of RPMs, you might also want to override the dependency checks when installing packages from one distribution on another, because different distributions sometimes use different names for equivalent packages.

The package database also allows detection of potential conflicts between packages. For instance, if minorlib and majorlib both provide a file called /lib/, and if you try to install both packages, the system will refuse to do so without an explicit override. This feature can help prevent problems caused by different versions of libraries or support files being installed by multiple programs or by simple name conflicts. Such problems are rare unless you mix overlapping packages from different distributions. For instance, Distribution A might split up a set of programs into client and server packages, whereas Distribution B might use library and program packages for the same set of tools. Attempting to mix packages intended for Distributions A and B can then cause file conflicts.

When it comes time to remove or upgrade a package, package management tools help immensely; you don't need to track down all the files for a package, which may be installed in half a dozen or more directories and under names that aren't obviously related to one another. The package tool checks the database and can delete all the required files, and then delete the entries in the package database. When upgrading a package, the system uses these entries to delete any files that have been removed from the newer package, so as not to leave obsolete files lying around.

Package management tools also enable you to track down the package to which a file belongs, obtain descriptions of the package, obtain a list of all the files in a package, and more. Packages are generally built using specification files and original source code. Source packages are available for most RPMs. These packages contain source code, patches, and a compilation procedure. You can use a source package to build a new binary package. You might do this to work around some types of dependency problems or to rebuild a source package for a CPU for which a binary package isn't available. Debian packages aren't available as source packages, but you can find the specification file to do much the same thing, when combined with an original source code tarball. Because there's less variation in the Debian world than among RPM-based distributions, this is seldom necessary, though.

Team LIB

0 0

Post a comment