[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Providing vi when /usr isn't mounted

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.

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

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 ?


Reply to: