/usr/bin/editor policy implementation
Dale writes:
> First: There are several packages that are classified as editors that
> clearly are not useful as the "default" editor. The two easy to
> understand examples are; addressbook, and beav. Addressbook is just
> that, and nothing more. It keeps its data in its own format and could
> do gross things if chosen as the default. (Imagine /etc/fstab being
> formatted as an addressbook) Beav, on the other hand, is a binary
> editor, and also a poor choice for a "default" editor.
No such program should provide editor alternative.
> Second: There are editors which come from non-free and are not always
> available with the distribution. In discussions with the maintainer of
> kedit it seemed we both concluded that it should be removed from the
> list. I am not completely sure that is the correct solution. So,
> there is some question about how to deal with non-free editors.
There is a political question and a technical question here. If the
politics were all the same then a non-free editor which was `better'
(ie, more likely to be a good choice for default editor) should have a
higher priority. update-alternatives will be quite happy to adjust
the default editor according to whether the non-free one(s) are
installed.
> Third: The use of negative priorities for those editors that require X
> window, or other "special" user interfaces is seen as an easy way to
> group those editors. This is not an indication of "value" and not
> intended to denigrate these products.
Such editors should not provide editor alternatives. Think about it:
alternatives are used automatically by the system (unless the system
administrator overrides, in which case they can set the link in
/etc/alternatives to be whatever they like) to set the default
editor. It would not be useful to have the default editor set to one
which only works (say) in X, unless the system is only ever going to
be used in X.
> Fourth: The space between the priorities, as presented in the
> following list, is intended to provide "slots" for additional editors,
> or for "reshuffling" positions of the current entries in the
> list. This is not a static pronouncement, but an adjustable framework.
This is good.
Ian.
Reply to: