On Thu, Sep 10, 2009 at 09:19:25AM +0200, Miquel van Smoorenburg wrote: > On Wed, 2009-09-09 at 19:02 -0400, James Vega wrote: > > tag 528494 help > > thanks > > > > #528494 raised the idea of having vim-tiny (the default vi-like editor > > on a base install) provide /bin/vi so that it would be accessible in > > situations where /usr isn't available. At first glance, I naïvely > > figured this would be an easy change. Of course, this wasn't the case > > so I'd like to get some feedback on the proper approach for this since > > this use case is actually something I've intended on doing since > > vim-tiny became Priority: important. > > > > We currently have 8 source packages[0] building binary packages which > > provide vi in some form. All except elvis-tiny use the alternatives > > system to provide /usr/bin/vi. Elvis-tiny ships /bin/vi which is a > > small binary implementing its own sort of alternatives functionality[1]. > > > > The problem here is that I can't simply have vim-tiny ship /bin/vi > > partly due to elvis-tiny but primarily due to the alternatives system > > rightly not supporting a provided alternative changing location > > depending on which of the available alternatives is active. > > [I sent this as a reply to bug #528494, but forgot to add Cc's, so > here it is again] > > Well, the original bug submission #528494 talks about that- you > cannot have different 'vi' binaries in /bin and /usr/bin, since > that would be very inconsistent. It's not purely about inconsistency. There's also the issue of having binaries installed in the /usr/bin and /bin with the same name. This prevents /usr/bin from being a symlink to /bin. How important that consideration is, I'm not sure. > What /bin/vi in elvis-tiny does is very simple: > > - if /usr/bin/vi exists, execute it (common case) > - else if /bin/elvis-tiny exists execute it (/usr not available) > - else print error and exit > > This way you always get /usr/bin/vi, even if /bin is in your > PATH first, unless /usr/bin/vi doesn't exist. > > We could work together to allow multiple '*vi-tiny' packages to > be installed, in that case we should really do the following: > > - each *vi-tiny package sets an alternative for /bin/vi-tiny > - each *vi-tiny package depends on vi-tiny-common > - vi-tiny-common is basically the /bin/vi from elvis-tiny, > as described above, where it tries to execute /bin/vi-tiny > instead of /bin/elvis-tiny A similar suggestion was made when on IRC. The difference being that /bin/vi checked for /usr/bin/vi.usr.bin and /bin/vi.bin in order to avoid the potential name collision. > However, to me this sounds as a lot of work for very little > gain. We already have the elvis-tiny package to provide a small > vi clone for situations where /usr is not available. This > would be a rescue situation. Is it really neccesary to be > able to choose between tons of vi-clones in that case ? The idea isn't to make people choose among tons of vi-clones any more than we “make” them decide among the various other alternatives that Debian's packages provide. The idea is to have the vi-clone that ships by default with Debian be available without /usr and to do so without preventing other vi-clones from being able to do the same thing. If the sysadmin chooses to install multiple vi-clones which provide a binary under /bin, they'll have the ability to choose which one should be used by default. Just like any other program that makes use of the alternatives system. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
Attachment:
signature.asc
Description: Digital signature