Re: Alternative program versions (eg vi)
Bill Mitchell writes ("Re: Alternative program versions (eg vi)"):
> This seems like it'll require a lot of coordination between maintainers.
The only coordination that is definitely required is agreement about
`master' names for groups of alternative versions. Priority ordering
does require a bit more, but update-alternatives can work without it.
> What about a conflictor who mistakenly ignores this and installs his
> program directly into the place where this had put a link?
Their program will be left in place, until they fix the problem, and
messages will appear from update-alternatives warning about it every
time it tries to install another one of the versions. When the
erroneous conflictor is fixed the next reinstallation of one of the
versions will put everything right.
> Is this now mandated?
Yes.
> If this is now mandated, will the priority-assigner please advise me
> what priority I should be using for elvis (installs alternatives vi,
> ex, input, and view in usr/bin and vi.1, ex.1, input.1, and view.1 in
> /usr/man/man1) -- other vi clones install other alternatives to
> some of these.
Do ex, vi, &c all need to be from the same version of vi, or does it
make any kind of sense to have ex be elvis (say) but nvi be vi ? If
the latter then ex and vi should be handled separately, and you'll
need two (or more) calls to update-alternatives.
I don't know about `vi' packages. You do, so please do what you think
feels appropriate and tell us what you have done so that the other
`vi' maintainers can follow suit.
There is no central priority assigner. In my last message I suggested
you use elvis=10 vim=20 nvi=30 unless someone has a better idea.
> Also, please advise me what priority I should be using for elv-fmt
> (installs alternative /usr/bin/fmt and slave /usr/man/man1/fmt.1)
> -- the textutils package installs an alternative to this.
As I wrote earlier:
Note that this script will *not* solve problems like mt-st vs
cpio-st. It is not intended to. I plan to introduce a different
mechanism to solve this kind of problem.
I don't believe the fmt problem is the same as the vi one. In
particular, I get the impression that elv-fmt is strictly better than
textutils's fmt.
> Also, what's the status of cpio:mt vs. mt-st:mt? If I need
> priority numbers for alternative /usr/bin/mt and slave
> /usr/man/man1/mt.1 for the mt-st package, please provide those
> as well.
As I wrote earlier:
Note that this script will *not* solve problems like mt-st vs
cpio-st. It is not intended to. I plan to introduce a different
mechanism to solve this kind of problem.
Richard Kettlewell writes ("Re: Alternative program versions (eg vi)"):
> Perhaps this problem could be solved by discussion between the
> maintainers of vi clones? OTOH perhaps this is an area which needs
> central decisions.
Do we have a volunteer to make the central decisions ?
Ian.
Reply to: