Re: Alternative program versions (eg vi)
I wrote:
> In the next version of dpkg, which should with a bit of luck be
> available this weekend, will contain a program for managing files like
> /usr/bin/vi which are symlinks each to one of a number of alternative
> versions.
update-alternatives is available in dpkg 0.93.72, which will be
available as soon as I have uploaded it. How to use the script is
probably best described by example - see below.
Maintainers of vi packages and other similar software should upgrade
ASAP and try it out. If there are no serious problems found they
should update their packages to use the new scheme ASAP - ie, delete
any special-case code for handling /usr/bin/vi and use this script
instead.
Each possible version of a particular piece of software needs a
priority number; for best results these numbers should be distinct. I
suggest that we use elvis=10 vim=20 nvi=30 unless someone has a better
idea. I don't know much about which `vi' clones are better, so input
here would be appreciated.
I'll be posting a copy of the script separately, to save people
downloading dpkg 0.93.72 just to look at it. Feel free to install it
in /usr/sbin - when you install the real version dpkg will overwrite
it.
Just for reference, here's the usage message:
chiark:~> update-alternatives
update-alternatives: need --display, --install, --remove or --auto
Debian GNU/Linux update-alternatives 0.93.72. Copyright (C) 1995
Ian Jackson. This is free software; see the GNU General Public Licence
version 2 or later for copying conditions. There is NO warranty.
Usage: update-alternatives --install <link> <name> <path> <priority>
[--slave <link> <name> <path>] ...
update-alternatives --remove <name> <path>
update-alternatives --auto <name>
update-alternatives --display <name>
<name> is the name in /etc/alternatives.
<path> is the name referred to.
<link> is the link pointing to /etc/alternatives/<name>.
Options: --verbose|--quiet --test --help --version
--altdir <directory> --admindir <directory>
chiark:~>
Here is what should probably be in the relevant bit of the vim
maintainer scripts, assuming vim has a priority of 10:
In the postinst script:
update-alternatives --install /usr/bin/vi vi /usr/bin/vim 10 \
--slave /usr/man/man1/vi.1 vi.1 /usr/man/man1/vim.1
In the prerm script:
if [ $1 != upgrade ]; then
update-alternatives --remove vi /usr/bin/vim
fi
The paths and arguments used in these calls are:
/usr/bin/vi The name of the primary link, by which people access
the program or whatever. update-alternatives will
create it when the first package is installed and
remove it when the last package is removed.
vi The name of the link in /etc/alternatives. This is
the one that the user may modify, and it is also the
one that update-alternatives modifies.
/usr/bin/vim The pathname for this `option', ie what the link
/etc/alternatives/vi should be made to point to when
this option is selected.
10 The priority level for the option. Unless overridden
by the user (by changing the link) the version with
the highest priority is selected; if a higher-priority
package is installed it will take precendence, and
when it is removed the next highest will be used.
/usr/man/man1/vi.1
The name of the primary link of a `slave' file, ie the
link to /etc/alternatives/vi.1. Slave files are
automatically kept in step with the master files.
vi.1 The name of the slave link in /etc/alternatives.
/usr/man/man1/vim.1
The path to have the slave link point to for this
option.
If the user changes /etc/alternatives/vi update-alternatives will
record the fact and no longer update the link; automatic updates can
be reenabled by deleting /etc/alternatives/vi or by using the --auto
flag.
If the user modifies a slave link like /etc/alternatives/vi.1 without
also modifying the main `vi' link then their change will be undone at
the next upgrade; if they modify /etc/alternatives/vi then none of the
slave links will be modified at all and the user becomes responsible
for all of them. Ie, the auto/manual flag is the same for the master
and all the slaves.
Several slaves may be attached to a single `master' file, by repeating
--slave and its arguments. The list of slaves from one --install
overrides the list from a previous --install *of the same master
option*, but does not override the slave list from other options. So,
for example, if one of the vi clones doesn't provide a manpage, but
provides a file in /usr/doc instead, then when it is selected the
manpage will not be available except by asking for a particular
version; likewise with the /usr/doc file when one of the others is
selected.
Ian.
Reply to: