editorrc as update-alternatives slave

[Thorsten Glaser <tg@mirbsd.de>]

Dear dpkg developers,

something came up with update-alternatives, and we would like to ask
you about whether this can possibly work. Context:

Dixi quod…

>Josip Rodin dixit:

>>We would want editorrc to depend on editor in some way, since that is indeed
>>logical, but IIRC you can't just invent new slaves to editor out of the blue
>>and expect other editor alternatives to play along - they wouldn't know how.
>
>Hm, these other editors could just have it dangling.
[…]
>Parallel to that, we ask the dpkg people if we can move to a
>slave, and include that in the upload if possible (since I've
>fixed it "for now", that upload isn't time critical).


At the moment, update-alternatives manages 'editor' which
consists of a binary symlink and one slave, being its
manpage symlink. For the editors joe and jupp, there is
also the 'editorrc' alternative which must also be set,
because they look up argv[0]+"rc" as configuration file
to use.

Could we add /var/lib/misc/editorrc (the new agreed-on
path for editorrc shared across jupp and joe) as slave
to update-alternatives for editor? Editors that don't
use it, like vi and nano, need then not define it and
will just have /var/lib/misc/editorrc dangling (or be
nonexistant), while editors that do define it (like joe,
jupp, and their variants jstar, jmacs, jpico, etc.) have
a symlink there which points to /etc/joe/joerc and so on,
depending on the editor choice.

Thanks in advance,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt