Bug#682347: mark 'editor' virtual package name as obsolete
Re-adding Jordi to this thread as the maintainer of GNU nano.
Christoph Berg <myon@debian.org> writes:
> I'm not vetoing any outcome - I'm just expressing my astonishment
> here. To me, the situation looks like that the current implementation of
> "editor" is like 80% ok, and because reaching 100% is hard (to which I
> agree), the whole thing is instead torn down. Can't we just stick with
> the 80%, given there's no actual problem with it?
I don't think that we're 80% of the way to an implementation of editor.
The majority of editors in Debian didn't Provide editor, and Policy
already explicitly said that there was no need to depend on editor. The
packages providing editor were a rather random selection (although to be
fair it did include both nano and vim).
I think there are three options, and I'd love to get feedback on which of
those three options we should take.
1. Status quo: there is an undocumented editor virtual package, Policy
says that nothing has to provide or depend on it, and some random
collection of editors provide it. I think this is a bad place to be,
so I would hope we can rule out sticking with that status quo.
2. Document editor and recommend everyone implement it properly. Since
we're going to allow packages to depend on editor, I think providing it
would need to be a should, so that's going to be a lot of buggy (but
not RC-buggy) editor packages. But it would get us to a clean
dependency system. (I will leave it to someone else to tackle this for
pager if someone really wants to.)
3. Mark editor obsolete, leaving only the alternative, and have people
just use that directly and assume it exists. (My previous patch.)
Note that if Policy is going to document that people can Depend on editor,
we have to either have a singleton default-editor virtual package or
require that all packages hard-code the default editor in the dependency
(with nano | editor). Otherwise, installing a package with an editor
dependency on a minimal system (nano is only important, so won't exist in
minimal chroots) is non-deterministic, with possible affects on everything
from reproducible builds to weird buildd behavior. The singleton virtual
package seems obviously best, so that would mean nano would Provide both
editor and default-editor.
I have a previous proposed patch in this thread for option 3. For the
sake of completeness, here's a proposed patch for option 2.
I'd love to have people weigh in on this. I know it's currently the
holiday season, so I'll probably need to ping this bug again in a week or
two to get more opinions.
Possible diff for option 2:
diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst
index 90ecf6d..82a886f 100644
--- a/policy/ch-customized-programs.rst
+++ b/policy/ch-customized-programs.rst
@@ -91,21 +91,30 @@ alternative should have a slave alternative for
``/usr/share/man/man1/pager.1.gz`` pointing to the corresponding manual
page.
-If it is very hard to adapt a program to make use of the EDITOR or PAGER
-variables, that program may be configured to use
-``/usr/bin/sensible-editor`` and ``/usr/bin/sensible-pager`` as the
-editor or pager program respectively. These are two scripts provided in
-the sensible-utils package that check the EDITOR and PAGER variables and
+Packages that register as an alternative for ``/usr/bin/editor`` should
+also provide the virtual package ``editor`` by including it in the
+``Provides`` control field. The package providing the current default
+editor for the Debian base system, and only that package, should also
+provide the ``default-editor`` virtual package. Packages that call
+``editor`` directly (not via ``sensible-editor`` or the EDITOR environment
+variable) should depend on ``default-editor | editor``.
+
+Programs may assume that ``/usr/bin/pager`` is available as a fallback
+without adding an explicit package dependency. There is no ``pager``
+virtual package.
+
+If it is difficult to adapt a program to use the EDITOR or PAGER
+variables, that program may instead be configured to use
+``/usr/bin/sensible-editor`` and ``/usr/bin/sensible-pager`` as the editor
+or pager program respectively. These are scripts provided by the
+``sensible-utils`` package that check the EDITOR and PAGER variables and
launch the appropriate program, and fall back to ``/usr/bin/editor`` and
-``/usr/bin/pager`` if the variable is not set.
+``/usr/bin/pager`` if the variable is not set. Packages using these
+scripts should declare an appropriate dependency on ``sensible-utils``.
A program may also use the VISUAL environment variable to determine the
user's choice of editor. If it exists, it should take precedence over
-EDITOR. This is in fact what ``/usr/bin/sensible-editor`` does.
-
-It is not required for a package to depend on ``editor`` and ``pager``,
-nor is it required for a package to provide such virtual
-packages. [#]_
+EDITOR. This is also what ``/usr/bin/sensible-editor`` does.
.. _s-web-appl:
@@ -572,10 +581,6 @@ installed in ``/usr/share/man/man6``.
portion is handled internally by the package system based on the os
and cpu.
-.. [#]
- The Debian base system already provides an editor and a pager
- program.
-
.. [#]
If it is not possible to establish both locks, the system shouldn't
wait for the second lock to be established, but remove the first
diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
index 4f82f88..ba1136b 100644
--- a/virtual-package-names-list.txt
+++ b/virtual-package-names-list.txt
@@ -82,6 +82,8 @@ Development
System
------
+ default-editor default base system /usr/bin/editor (*)
+ editor suitable /usr/bin/editor (*)
flexmem anything that can access flexible memory via the
OBEX Protocol
foomatic-data PPD printer description files
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: