Files which want to be different in different packages
It seems to me that we do indeed have a requirement that is not
addressed in our current scheme of things.
The problem occurs when several packages may wish to provide a file of
the same name. Sometimes this contested name can be a symbolic link
to a package-specific name; in other cases one of the packages
reasonably wants the name for itself and another wants to displace it
somehow.
I can think of at least four examples where one might consider this
problem existed. I'm going to use these as references for what
requirements we have. (The best way to discover one's requirements is
through experiment and experience, and it seems to me that our
experience here is best represented as examples.)
* /usr/bin/vi: elvis vs. nvi vs. vim
Here several packages `compete' for the name /usr/bin/vi. Users
need to be able to specify which `vi' they want by using the specific
name (`elvis' or whatever), but the name `vi' needs to refer to a
sensible default. Usually this should happen without prompting across
installations and removals of various `vi' versions, but the sysadmin
should have the opportunity to override any automatic redirections.
* /bin/ls, /usr/bin/ls: normal ls vs. colour-ls
Here the situation is slightly more complicated. *A* sensible ls
needs to exist in /bin. It is unclear in this example whether it is
necessary for the standard fileutils ls to be available in /bin - let
us assume that there will be conflicts of this kind where this
question is resolved either way, so that any solution must attack both
problems. Once again, the sysadmin may specify which `ls' the name
`ls' refers to - in this respect, it is similar to `vi'. However, the
`fileutils' package is a base package, which may make a difference.
(I'm assuming here that the colour-ls features aren't `sensible'.
Clearly a better solution would be to have our standard ls be the best
ls we can provide, namely a sensible colour-ls. There might also be
copyright problems with such an approach, though this isn't the case
with colour-ls.)
* smail-wrapper: /usr/bin/smail
I haven't discussed this here before, but in some environments with
which I'm familiar it is be useful to be able to put a wrapper program
around the smail binary (I won't go into detail). In other situations
too it may be useful to be able to package packages that `wrap'
themselves around standard programs, without having to produce new
packages that include all the stuff in the standard onces. Here it is
not reasonable to expect the `standard' package maintainer to do
something odd to their package to sort this out, and in any case the
user wouldn't want to see silly redirections (eg smail -> smail.real)
on a `standard' system.
* cpio-mt vs. mt-st
Clearly the solution here is to get the GNU cpio maintainer to use
the better st program, and in the meantime to update the Debian cpio
package to include it regardless of the GNU cpio package's contents.
However, this may not always be the case. In some circumstances some
users may have a legitimate need to replace a program, without that
replacement being beneficial to all users. If we accept this argument
we end up with a requirement similar to the `wrapper' one above.
In each case I think we should drive the design and implementation
from the desired results in the user's filesystem.
* In the case of vi it is clear that each package should contain
/usr/bin/elvis or whatever, and that /usr/bin/vi should be a symlink
of some kind. The requirement to allow the system administrator
control shows that we need /usr/bin/vi to be a link to /etc/vi (just
like /etc/X11/X), or that we must require the system administrator to
use /usr/local/bin/vi and put that first in the PATH and tell the
sysadmin that we're doing so.
* In the case of colour-ls we need to be able to support either:
- /bin/ls is usually just the normal ls and is entirely replaced by
colour-ls if it is installed, and the real ls is moved aside and
replaced if colour-ls is deinstalled; or:
- /bin/ls is always a symbolic link, usually to ls.standard or
something (this is I think the same as the `vi' situation, except with
the added requirement that `ls', unlike `vi', may not be left dangling
even if the user tries to make it be so).
* In the case of wrapper programs we need too be able to move aside
the real program, and upgrade it in its `moved-aside' location, until
the `wrapper' package is removed. At that point it should be moved
back. This, I think, turns out to be the same as the first ls
requirement.
* In the case of mt-st I think we have the same requirement as with
wrapper programs.
This leads me to think that we have two specific requirements/features
which aren't currently supported/available:
1) A package should be able to arrange for a particular file or
file(s) from another package to be installed in a name other than the
one the original package maintainer intended, so that it can install a
file of that name. The `overriding' package needs to specify such
files explicitly, and give the new name (usually <foo>.real or
<foo>.std or some such). When the `overridden' package is updated the
updated version should be installed in the modified location, and when
the `overriding' package is removed the file should be put back.
What should the behaviour be if two packages attempt to `wrap' around
or `replace' the same program ? Either we need to figure out a
priority-ordering, or we need to forbid this case. Priority ordering
seems to me to be unlikely to be useful in most cases; rather, it is
likely to cause problems as the many packages will have conflicting
expectations. I therefore think that this should be forbidden.
This seems to me to be a possibly-controversial design requirement, so
I'll leave discussing possible implementations for now, until I'm
convinced that this idea is good and has general backing.
2) There should be an easy and at least semi-automatic (from the
package maintainer's POV) mechanism for the maintenance of
`preference' symlinks like /usr/bin/vi. Each package providing a
possible target needs to specify a priority in some way (numerically
would seem best), and the link needs to be maintained automatically
(from the user's POV) so as not to be left dangling.
If the user manually specifies the link target in some obvious way
this should be handled in accordance with the user's wishes, in some
sense, except that for some programs it should be difficult for the
user to cause a sensible version of the program to be available.
It seems to me that this objective is most easily met by the following
specification:
The variant link is always in /usr/bin or /bin and depends only on the
combination of installed packages; the sysadmin should use
/usr/local/bin for any local configuration of this type.
(/usr/local/bin is rightly before the system directories in the
standard PATH.) This will ensure that when the sysadmin's preferred
program is removed the distributions's preference will take over.
Note that there is no requirement for the sysadmin to be able to force
`vi' to be unavailable.
A new script, along the lines of update-rc.d &c, is provided, for
retargeting links. It takes the name of the link, the name of the
possible target, and an option argument saying whether the package is
being added or removed.
Before acting it uses state info in /var/lib/dpkg to determine whether
the link is the way it `left it'. If it is not it goes into a
dialogue with the user, offering to move the link to /usr/local or
simply to ignore/overwrite it. This will allow the system to detect
`meddling' by the user and help them out.
Then it determines what the new state should be (from the new
availability of the various targets and their preferences as recorded
in previous invocations) and sets the link to suit. When the last
available target is removed the link is removed too.
Ian.
Reply to: