Talk:Policies/Alternatives/Vi Change Proposal
From Mandriva Community Wiki
This document lists problems existing with the current setup of the vi(1) editor in Mandriva Linux and presents a solution proposal.
Contents |
[edit] Introduction
[edit] The vi editor
The vi editor is the standard screen-oriented editor in POSIX systems. Numerous vi implementations are available today, each one with specific features and possibly enhancements over the original vi. A modern Linux distribution is usually able to allow the user to select its preferred vi editor among several installed implementations using the Debian alternatives system. At least one vi implementation must be installed on the system for POSIX and LSB compliance.
[edit] References
The problem was discussed with John Campbell and Luca Berra in the Cooker mailing list. See the vi and uvi thread for details.
[edit] Current setup
[edit] Description
The current vi setup in Mandriva Linux provides a minimalistic vi implementation for system recovery or small systems based on the Vim editor built without non-essential options (vim-minimal) and a full-fledged implementation based on the complete Vim (vim-enhanced). Many features of the full-fledged vi implementation are desirable in a system under normal conditions, but it's not suited for system recovery or small system because it's too large and requires components installed under /usr (which may not be available on system recovery). The minimalistic vi implementation should be usable without /usr being mounted on the system.
Fig. 1: Current package layout
The Current package layout is displayed as a graph in Fig. 1. Rectangular nodes represent virtual packages and cyan edges are alternatives.
The Debian alternatives system is used to provide two links: /bin/vi (vi) and /usr/bin/vi (uvi). vim-minimal is installed as /bin/vim-minimal and doesn't require components installed under /usr. vim-enhanced is installed as /usr/bin/vim-enhanced. In a system recovery situation with no /usr available, vim-minimal should be used. In normal system operation, provided that vim-enhanced is installed, vim-enhanced is used as the default vi.
[edit] Problems
The current implementation has a major problem of having both /bin/vi and /usr/bin/vi links pointing to the same editor. It works when only vim-minimal is installed in case of system recovery, but fails when /bin/vi points to /usr/bin/vim-enhanced and /usr is not mounted.
The following table shows the possible situations and the corresponding system response when vi is invoked (assuming that /bin comes before /usr/bin in the user's PATH).
| vim-enhanced not installed | vim-enhanced installed | |
|---|---|---|
| /usr mounted | executes /bin/vi (points to /bin/vim-minimal) | executes /bin/vi (points to /usr/bin/vim-enhanced) |
| /usr not mounted | executes /bin/vi (points to /bin/vim-minimal) | FAILS |
Another problem arises from the fact that vim-minimal is not required by the base system. Instead, the virtual symbol "vim", provided by vim-minimal and vim-enhanced, is required, so that vim-enhanced can be part of a base system, without vim-minimal. In this case, we have:
| vim-enhanced only | both installed | |
|---|---|---|
| /usr mounted | executes /bin/vi (points to /usr/bin/vim-enhanced) | executes /bin/vi (points to /usr/bin/vim-enhanced) |
| /usr not mounted | FAILS | FAILS |
Clearly, vim-minimal is not effective when vim-enhanced is installed, the result of invoking "vi" are the same regardless if vim-minimal is installed or not.
[edit] Proposed change
[edit] Description
The problem can be solved in a simple and elegant way using a wrapper. This wrapper is installed as /bin/vi and executes /usr/bin/vi if available, or the recovery vi otherwise. Provided that the minimalistic vi is always installed, this solution covers all possible situations of /usr being available or unavailable and more advanced vi implementations installed or not. (Another wrapper solution is vi_wrapper bash script.
Fig. 2: Proposed package layout
Suppose the case when a full-fledged vi editor is provided by /usr/bin/vim-enhanced and the minimalistic vi is /bin/elvis-tiny. Elvis-tiny is actually a good candidate for the system default vi because it's very small (around 64Kb) and has all the required functionality of a system recovery vi. vim-minimal is larger (around 420Kb) and can still be available as a vi alternative. In this case, all possible situations are depicted in the following table:
| vim-enhanced not installed | vim-enhanced installed | |
|---|---|---|
| /usr mounted | executes /usr/bin/vi (points to /bin/elvis-tiny) | executes /usr/bin/vi (points to /usr/bin/vim-enhanced) |
| /usr not mounted | executes /bin/elvis-tiny | executes /bin/elvis-tiny |
Another possible solution with elvis-tiny used as the minimalistic vi implementation is to drop vim-minimal and collapse vim-enhanced with vim-common into a "vim" package. In this case, the layout would be simplified to the situation shown in Fig. 3.
Fig. 3: Simplified package layout
[edit] Benefits
The proposed solution for the problem has several advantages:
- Functionality: Invocation of vi works when a better vi is installed but /usr is not mounted.
- Consistency: System behavior is consistent between normal operation and system recovery cases. In both scenarios an editor is executed when the user invokes vi. The same editor is executed when the user invokes vi, /bin/vi or (if available) /usr/bin/vi.
- Size: Usage of an even more minimalistic vi implementation (elvis-tiny) reduces the size of the system core for the "Small System" case. Extra features provided by vim-minimal are not essential in the system recovery situation.
- Robustness: The proposed solution independs of the order of /bin and /usr/bin in the user's PATH enviroment variable. Also the wrapper prevents self-invocation and exits gracefully with an error message in case of system problems.
- Compatibility: It retains the ability to install many vi implementations concurrently using the Debian alternatives system.
- Transparency: The wrapper uses an exec() call to run the editor and does not fork a different process.
[edit] Implementation
Implementation of the proposed change requires careful planning of the upgrade strategy in such a way that the user would never have the system in inconsistent state or without a valid vi editor in the system. A suggested sequence of actions follows, but these must be reviewed and tested prior to implementation.
- Create package elvis-tiny containing the /bin/vi wrapper (cannot coexist with older vim packages because it takes over /bin/vi).
- Basesystem is changed to require elvis-tiny instead of vim.
- vim-minimal and vim-enhanced are changed to provide vim and vi, and to provide alternatives to /usr/bin/vi (vi). New vim packages conflict with older basesystem versions, so upgrading vim alone would require installation of elvis-tiny and wrappers via the dependency chain. Alternatively, vim-minimal can be dropped and vim-enhanced joined with vim-common in the "vim" package.
Alternatives priorities could be changed so a wider range is used for vi (currently vim-minimal has priority 10 and vim-enhanced priority 20). The suggested range for priorities after implementation of the new layout is:
| Editor | Old Priority | New Priority |
|---|---|---|
| elvis-tiny | N/A | 10 |
| nvi | 7? | 30 |
| vim-minimal | 10 | 50 |
| elvis | N/A | 70 |
| vim-enhanced | 20 | 90 |
[edit] Summary
This proposal solves the current vi accessibility issue on a system recovery scenario where /bin/vi be a broken symbolic link. Additionally, usage of elvis-tiny instead of vim-minimal as the essential system recovery vi reduces the core system footprint with little or no disadvantage over vim-minimal in a system recovery scenario. The solution is based on a combined wrapper+alternatives approach which is architecturally elegant, flexible and robust. Similar solutions are used in Conectiva Linux and Debian.
[edit] Comments
-- VincentPanel - 08 May 2005 : Very interesting and complete document. I would suggest a shell wrapper instead of the C wrapper because it's simpler and more transparent for users. I would remove some checkings : user isn't supposed to mess with system files and if she does, she probably know what she's doing. You can see my proposal in attachment.
