Software Management/rpm-only

From openSUSE

RPM-only software management

Traditionally, (open)SUSE has supported higher level software elements (beyond packages) to provide enhanced functionality and usability of its software tools.

Cons

Just looking at (RPM) packages is insufficient at a couple of places

• Package selection overflow

Having lots of packages to choose from is a good thing. However, having too many packages is a burden. One needs some means of selecting and grouping to get the view down to a manageable size. Initially YaST supported selections which were basically lists of packages used as install macros. The installer iterated through the list and tried to install each package. If a package was not available, it was silently discarded. Installation of selections was not tracked.

With Code10, the concept of selections was extended to Patterns. Patterns are first-class objects with dependencies to either other patterns or packages. The pattern-pattern dependency allows to express building blocks by assembling patterns from other patterns. The pattern-package dependency allows to express functional blocks by requiring packages to be installed. To the user, patterns provide grouping reducing thousands of packages to a couple of dozen patterns.

• Update underinformation

Packages and updates for packages do not provide a reason (well, except for newer version) for an update. This might be sufficient for the casual user but is not for the enterprise. Here one wants to know the severity (security?, functional enhancement?) and detailed information (whats the bug ? Is my system affected ?) to decide to install the update or not.

Proper update management requires more than just packages.

• Providing maintenance

The business model for Linux vendors is free software, payed maintenance. The latter part needs tracking of the product and if the system is eligible to receive updates. It allows also for some nice features, like automatic update channel assignment.

Pros

• Common denominator

Any software management element except (RPM) packages is vendor-specific and does not play well (not at all in most cases) with other tools. The RPM database is the least common denominator for RPM-based Linux distributions.

• Authorative source of information

Every software management tool uses the (RPM) package database, it is considered an authorative source of information about the state of the system concerning installed software packages. RPM takes great care to protect its database and provides functions to recreate it in case of crash.

• Upstream integration

Working on (RPM) packages only makes it easier to integrate with solutions and tools provided by the open source community.