Multi-Version and Install-Only Policy

Multi-Version and Install-Only Policy defines the framework and guidelines under which multiple versions of software packages can coexist on a Linux system, as well as the rules governing installation methods that avoid overwriting or removing existing package versions. This policy ensures compatibility, stability, and flexibility in package management by supporting scenarios where different applications or users require different versions of the same software simultaneously.

Purpose and Scope

Purpose

The primary purpose of the Multi-Version and Install-Only Policy is to provide a systematic approach for handling software packages that need to be installed in multiple versions on a single operating system instance. It addresses conflicts arising from version dependencies, runtime compatibility, and software development needs, allowing users and administrators to select or switch between versions without disruption.

Scope

This policy applies to all packages distributed via the system’s package management infrastructure, including base system packages, third-party software, and development libraries. It covers version naming conventions, file system layout, packaging metadata, installation behavior, and interactions with package managers such as rpm or dpkg.

Multi-Version Support

Definition of Multi-Version Packages

Multi-version packages are those designed to allow more than one version to be installed and used concurrently on the same system. These packages typically provide software that may have incompatible interfaces, APIs, or runtime environments that prevent straightforward upgrades or replacements.

Criteria for Multi-Version Eligibility

Not all packages qualify for multi-version installation. Eligibility depends on factors such as:

• Backward compatibility: Packages that break backward compatibility between versions.
• Runtime requirements: Software that requires specific versions for different applications.
• Development needs: Libraries and tools used for compiling or linking that support multiple ABI versions.
• User demand: Popular software where multiple versions are commonly needed, e.g., language runtimes (Python, Ruby), databases, or compilers.

Package Naming and Versioning

Multi-version packages must use explicit versioning in their package names to avoid collisions. For example, a package for version 1.2 might be named python2.7 while version 3.8 is python3.8. The naming convention should ensure uniqueness and clarity, reflecting the actual upstream version.

File System Layout

To facilitate coexistence, files from multi-version packages are installed into dedicated directories that include the version number. For instance:

• Executables might reside in /usr/bin/python3.8
• Libraries can be installed in /usr/lib/python3.8/
• Configuration files remain version-specific or are placed in separate directories.

Symlinks or environment modules may be used to provide default version references or to switch between versions dynamically.

Install-Only Packages

Definition of Install-Only Packages

Install-only packages are packages that, once installed, do not replace or upgrade existing versions but rather install alongside them. This approach avoids automatic removal or overwriting of previous versions, preserving the older packages intact.

Use Cases

• Software requiring multiple installed versions without conflict.
• Packages providing tools or libraries that must coexist for compatibility reasons.
• Vendor or third-party packages distributed in parallel to system packages.

Package Manager Behavior

Package managers must treat install-only packages specially by:

• Avoiding automatic replacement or removal during upgrades.
• Allowing multiple instances of the package name differentiated by version.
• Managing dependencies and conflicts carefully to prevent breakage.

This may involve custom metadata flags or versioning strategies within the package metadata.

Dependency and Conflict Management

Dependency Specification

Multi-version and install-only packages must specify dependencies carefully, often pointing to versioned dependencies explicitly. For example, a package requiring Python 3.8 libraries should depend on the python3.8 package explicitly rather than a generic python3.

Conflict Resolution

To prevent conflicts, the policy mandates:

• Declaring conflicts only when versions truly cannot coexist.
• Using versioned provides and obsoletes fields with precision.
• Avoiding unversioned virtual provides that could inadvertently block multi-version installs.

Upgrade and Removal Policies

• Upgrading a multi-version package installs the new version alongside the old unless explicitly removed.
• Removal operations should not cascade to uninstall all versions unless user explicitly requests.

User and Administrator Interaction

Version Selection and Defaults

The system should provide mechanisms to select default versions for commands and runtime environments, either through:

• System-wide alternatives or update-alternatives mechanisms.
• Environment modules or shell wrappers.
• Explicit invocation of versioned binaries.

Documentation and Communication

Packages must clearly document:

• Supported multi-version behavior.
• Installation directories and version suffixes.
• Instructions for switching versions or setting defaults.

Administrators should be aware of the implications of installing multiple versions and managing system defaults.

Packaging and Build Guidelines

Build-time Configuration

Packagers must configure builds to support versioned installation paths and avoid hard-coded paths that conflict with multi-version coexistence.

Metadata Annotations

Package metadata should include tags indicating multi-version or install-only status to enable package managers and tools to handle them appropriately.

Testing and Validation

Multi-version packages must undergo testing to ensure they install correctly alongside other versions, do not overwrite shared resources, and function independently.

Security and Maintenance Considerations

Security Updates

Security patches must be applied to all maintained versions to prevent vulnerabilities in older versions remaining installed.

Maintenance Burden

Supporting multiple versions increases packaging and maintenance workload; this policy encourages evaluating whether multi-version support is necessary or if a single version suffices.

Deprecation and Removal

When older versions become obsolete or unsupported, policies should guide their phased removal while ensuring dependent software is migrated appropriately.

Summary of Key Policy Points

This policy ensures that Linux package ecosystems can support complex software requirements involving multiple concurrent versions, maintaining system stability, usability, and security.