Defining Linux Knowledge

The system dependency server is the heart of Sun Update Connection – Enterprise. It contains the dependency manager and the knowledge base.

Your local knowledge base, pulled from the universal server plus local software and data that you pushed from your hosts (to the local knowledge base, never to the Universal Server on the Internet), contains the following Linux information:

• Linux components – Logical units that are, or can be, part of a system. For example, RPMs, drivers, modules, and symbols.

• Dependency rules – Instructions for successful installation of a component and all of its dependent components.

  The dependency manager, or Engine, manages the agents. The Sun Update Connection – Enterprise agent is installed on every managed host and runs the Dependency Resolver, the application that finds the most cost-effective solution for jobs. In this way, every managed host finds the best solution for its own software configuration. Agents solve jobs with rules and components.

RPM Components

A component is anything that can be downloaded and installed on a system. Most of the certified components on the universal server are RPMs.

Linux is not developed by a single company. Instead, thousands of independent, Open Source developers constantly update and improve the Linux operating system. There are tens of thousands of components available for download and installation.

The RPM Package Manager brings some order to the chaos. The idea of a Linux package provides a standard for independent developers to offer their applications for distribution. The RPM standard describes how to name a package, how to structure its format for consistent management, and the type of data it should or may contain.

A set of components packed with the RPM engine is also called an RPM and is also packed with the following data:

• Date, time, version, release, and environment (such as Intel or zSeries)

• Description of the packed components, including the following: names, size, installation paths, permissions, owners, general security checks, and file contents.

• Reference to other components. For example, what it is similar to, what it is dependent upon, and what it conflicts with.

• a signature to verify authenticity

To Create an RPM

1. Collect the source files of the application and any new updates.

2. Write the specification file containing packaging scripts run by the RPM engine and a file list.

3. Run the RPM Engine with flags to build the package.

   Notice that the RPM procedure is rather loose. The developer can decide which source files to include in the package. Other files, such as libraries and basic operating system components, may be simply pointed to in the reference data as dependent packages. This means that the end user must make sure that all packages that the developer assumed were already installed are, in fact, on the system.

   When the user installs an RPM, the scripts (written by the developer, not created by an automated standard) are run and tell the user the following information:

   • If dependent components need to be installed

   • If there are installed components that conflict with files in the package

   • The version range of dependent components and conflicting components

Dependency Rules

Most Linux components depend upon the prior installation of existing libraries or other packages to operate in known system configurations. These other components are dependent components. For example, kdesdk*.rpm needs gcc-c++ to be installed.

When components need incompatible versions of dependent components, a dependency conflict arises (packages or files that should not exist on the same system as the base component, such as an earlier version). For example, if mysql-devel is installed, MySQL-devel does not work.

Descriptions of dependencies and dependency conflicts are called rules.

To install a component manually, without using Sun Update Connection – Enterprise, you must discover and install the complete dependent component list before you can install or run the original component. When you install a component with Sun Update Connection – Enterprise, dependency issues are taken care of automatically. In addition, the rules of the knowledge base are exact and accurate, while the rules included in an Open Source package may not be.

Standard Dependency Rules

Open Source packaging rules are based on loose standards.

Package developers might write very specific dependency rules, but the rules might be more restrictive than necessary. For example, a specific set of rules might say that you need at least version 1.5 of a software package. You have version 1.3 of the software and upgrade to a version that meets the dependency rules. However,v it could be that earlier versions are not in the rules because the developer did not test those versions.

Other developers might be to general when writing the dependency rules, and you might encounter conflicts even if you follow the rules.For example, a general set of rules may say that you need version 1 to 3 of a software package. Another developer creates v2.9, which causes a conflict with your other installed components

Sun Update Connection – Enterprise Dependency Rules

The dependency rules in the knowledge base are exact, neither too specific nor too general.

For example, the standard rules for SuSE’s dia-0.85-34 package (an application for creating diagrams and flowcharts) say that this package needs libxml of any version. Among the certification tests, the dia package was installed on a system with libxml-1.7.3-3. An installation error resulted. Running more tests, the exact Sun Update Connection – Enterprise rule was created: dia-0.85-34 needs libxml from version 1.8.6-18.

The Certification Lab tests every component and finds its exact installation rules, listing, including the following:

• All dependent components

• All component conflicts

  In addition, if a dependent component has its own dependencies, this is also known. There is no limit to the number of levels that Sun Update Connection – Enterprise takes into account.

  The knowledge base contains the dependency rules, and Sun Update Connection – Enterprise uses it to automate functional installations. Sun Update Connection – Enterprise also finds potential conflicts, warns you of them, and suggests alternatives before you install a component.