Bug#528494: vim-tiny: move to /bin?

[Miquel van Smoorenburg]

According to James Vega:
> In looking at the following request for vim-tiny to provide /bin/vi I
> noticed that elvis-tiny already provides such a binary.  In order to
> fullfil this request, I'd like to ask that elvis-tiny switch to using
> alternatives for /bin/vi.
> 
> The plan that I would like to move forward with is for both vim-tiny and
> elvis-tiny to provide their binary under /bin and then use alternatives
> to provide /usr/bin/vi and /bin/vi (as a slave of the /usr/bin/vi
> alternative).
> 
> This looks similar to what elvis-tiny is already doing except it has an
> odd /bin/vi binary (generated from debian/wrapper.c) doing the work
> instead of utilizing alternatives.

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 ?

Mike.