From Mandriva Community Wiki

NOTE: This was originally "AlternativesPolicyReview" but since this seems to be a proposal writetn by Claudio Matsuoka, I felt it was better to put this on the "Talk" page as that's what those pages are for)

Contents 1 Introduction 2 References 3 The guidelines 3.1 When use alternatives 3.2 Naming policy 3.3 Installation 3.4 Default version 4 Proposed new guidelines 4.1 When alternatives should NOT be used 4.2 Canonical name provided in package 4.3 Mandatory requirements 4.4 Priorities 4.5 Single alternative link 5 Conclusion

Introduction

This is a review of the Policies/Alternatives document, subtitled "Policy regarding several versions of a same package", which contains instruction on how to manage different versions of a same software in Mandriva Linux simultaneously using the Debian alternatives system. This document reviews the existing policy and extends it to the generic alternative file case where two or more packages offer the same functionality (e.g. mta) or different implementations of the same tool (e.g. vi, yacc).

The alternatives system was written in Perl by Ian Jackson for Debian's Dpkg package manager. A version in C was implemented by Erik Troan for Red Hat Linux. Mandriva Linux uses the Debian version.

References

• Policies/Alternatives: How to manage different versions of a same software in Mandriva Linux simultaneously.

The guidelines

When use alternatives

The Alternatives Policy cites two cases where the alternatives system should be used: unstable versions and incompatible versions that can't be easily migrated by an automated, script-driven process.

Proposal: add the generic case of similar functionality or different implementation of the same tool.

Naming policy

The current policy states that alternative file names "should be the name of the package, with the major version appended directly", except when the package ends in a number or minor is required. This policy adds unneeded complexity in the generic case (e.g. yacc can be implemented by byacc or bison, and there's no point in installing byacc as /usr/bin/byacc1 and bison as /usr/bin/bison2).

Proposal: State that this rule applies only in the multiple versions case, and let the mantainer choose the most appropriate name for alternative files in the other cases.

Installation

This topic covers a case where there's no parallel installation, i.e. there is only one single alternative at a time. There's no need to use alternatives in this case, as a package-provided symlink would suffice.

Proposal: Don't use alternatives in this case.

Default version

According to the current policy, "the default version of a package should be the simpler one". This only applies in the multiple versions case. It may cause annoyances when the default package changes and the user has to reinstall a payload it already has on her machine, and migrate configuration files installed on directories named after the versioned package name.

Proposal: When multiple versions of a package are to be installed simultaneously, let each of them have versioned names. The default version carries the canonical name. This may not be the best solution aesthetically, but has practical advantages. Package renaming should generally be avoided.

Proposed new guidelines

When alternatives should NOT be used

This topic isn't covered by the policy at all. Common pitfalls in alternatives abuse are: libraries, different versions that should be switched according to enviromental factors (e.g. running kernel version) and cross-filesystem cases where the actual executable resides in a filesystem that may not be mounted at invocation time (see Talk:Policies/Alternatives/Vi_Change_Proposal).

Canonical name provided in package

This also applies to the third case when there are different packages providing the same functionality or implementing the same tool. The canonical name (i.e. the name providing a common interface to the alternative files) should be provided by the package. Example: both byacc and bison should provide the symbol "yacc", and a package requiring "yacc" would have its dependency satisfied by either byacc or bison.

Mandatory requirements

Packages using the alternatives system should require the "alternatives" functionality instead of the /sbin/update-alternatives implementation (doing so also saves an indirection in the dependency chain).

Priorities

Single alternative link

(for consistency. cite sendmail case)

Conclusion