Virtual package name 'editor' was removed from Authoritative List of Virtual
Package Names in 1996 year, but it is used at our days. Maybe we need to add it
to section "Old and obsolete virtual package names", which is empty? If yes,
we need to file a bug against each package that uses it, so this name will be
removed from repository. If no, maybe we need to add it again in the List?

Hello Artem,
As far as I see, no packages Depends/Recommends on "editor", thought there are
still a number of package that Provides: editor.

Since the editor virtual package is not defined, bugs should be reported against
packages that still provides it.

Cheers,

This is the list of packages that 'Provides: editor'

fte-console fte-terminal fte-xwindow
jove
jupp
le
levee
mg
nano nano-tiny
ne
scite
vigor
vile xvile
vim vim-tiny

Not sure whether it is wortwhile to reort all these bugs.

Cheers,

(Adding the maintainers of the affected packages via Bcc.)

Artem Leshchev <wolf@gwerewolf.ru> writes:

Would anyone on the Policy list or any of the maintainers bcc'd want to
make a case for keeping the virtual package "editor"?

In previous discussions, no one seemed to feel that it was helpful as a
virtual package.  Virtual packages are only useful for another package to
depend on (or recommend or suggest), or for someone to manually use as in
"apt-get install editor", neither of which seem like useful actions here.
(Or to conflict with, but that's obviously wrong here.)  No packages
currently declare any type of dependency on editor.

While an argument could be made that the highest priority of any editor is
in Debian is important (so far as I can see) and therefore a package that
requires (any) editor could want to declare a dependency, we've not done
this in Debian for many years and we seem to have never noticed the lack.
A local administrator can always set EDITOR or VISUAL, and an interactive
editor is a very unlikely critical dependency for the sort of package that
needs to operate on a minimal system.

Note that this doesn't change the editor *alternative*, which is
documented in Policy and will continue to work as it does now.

If there are no objections, I propose the following patch, which I believe
documents the current practice in Debian.  This patch also makes explicit
that packages that rely on sensible-editor or sensible-pager *do* need to
declare a dependency on sensible-utils (which should be common sense, but
which seemed worth calling out anyway).

diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst
index 90ecf6d..9c17c1a 100644
--- a/policy/ch-customized-programs.rst
+++ b/policy/ch-customized-programs.rst
@@ -93,19 +93,21 @@ 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
+``/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
 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.

No strong objection to removing this virtual package.

Note that there *are* a handful packages which still depend/recommend/suggest
editor and will need bugs raised along with those for the editors providing
it.

  $ apt-cache showpkg editor
  Package: editor
  Versions:

  Reverse Depends:
    dnsvi,editor
    xpaint,editor
    udo-doc-en,editor
    udo-doc-de,editor
    libproc-invokeeditor-perl,editor
  [...]

Dropping Artem, whose email address no longer works.

Brendan O'Dea <bod@debian.org> writes:

Oh, thank you!  For some reason, apt-cache rdepends didn't show any of
those packages.  All of them except dnsvi are Suggests, which basically
doesn't accomplish anything.

Copying myon on this message as maintainer of dnsvi, which has a
dependency on "vim | editor".  Christoph, we're proposing finally removing
the editor virtual package completely, with the patch included here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682347#20

Re: To Russ Allbery 2017-08-24 <20170824171653.r24gyar5mikyje7q@msg.df7cb.de>

There are some false positives in that list (deutex, ledit, pluma,
rlwrap, xul-ext-exteditor; "Provides: readline-editor" and similar),
but the list is still pretty long, I'd conclude.

Christoph

Re: Russ Allbery 2017-08-24 <87efs1lyc7.fsf@hope.eyrie.org>

Thanks for the notice. I'm quite surprised that my dnsvi seems to be
the only package in Debian that requires a text editor. Given that our
base doesn't really include one, and getting dependencies Just Right
is among the things that Debian is really good at, dropping the
existing "editor" virtual package seems Just Wrong to me.

Even if "editor" was de-officialized in 1996, it is very much used
today. Bill's original list from 2015 was incomplete (it is much
longer now, but given that even emacs was missing, I'd think the grep
command used back then was wrong):

$ grep-dctrl -F Provides editor -nsPackage /var/lib/apt/lists/deb_debian_dists_sid_main_binary-amd64_Packages | xargs
deutex edbrowse emacs25 emacs25-lucid emacs25-nox fte-console
fte-terminal fte-xwindow jed xjed jove jupp le ledit levee lpe mg
xul-ext-password-editor nano nano-tiny ne pluma rlfe rlwrap scite
vigor vile xvile vim vim-athena vim-gtk vim-gtk3 vim-nox vim-tiny vis
xul-ext-exteditor

Wouldn't it much better (cleaner, more correct, more userfriendly) to
promote "editor" to official status instead?

Christoph

Hi,

Russ Allbery wrote:
[...]

One change this patch makes is to talk about /usr/bin/editor and
/usr/bin/pager files instead of editor and pager files.  Is that
intentional?

E.g. git uses "editor" as its default editor, not /usr/bin/editor.

[...]

What should packages do if an editor is configured and the "editor"
command is not available?

That's an existing issue but I had never thought about it before.  It
would be nice if policy could say something about it.

Thanks,
Jonathan

Christoph Berg <myon@debian.org> writes:

Yeah, that gut instinct resonates with me too.  But... we've not done this
since 1996, so is it worth the effort to try to get everyone to change?  I
feel like going the other route would be some amount of work for a bunch
of packages with no perceivable benefit in Debian.

I can write language for that instead, but I know way, way more packages
assume that editor is available than currently depend on it, and I'm
reluctant to declare them to be buggy.  You seem to be the only package
maintainer who was using this "correctly."

Note that if we do go down the path of making it official, we'd probably
need to introduce something like default-editor and standardize a
dependency of default-editor | editor, so this is a non-trivial amount of
work.  (You don't want a package to depend on editor and pull emacs25 into
a minimal chroot because that happened to be the first package providing
editor that apt saw.)  For instance, you depend on vim | editor right now,
but vim is quite heavy-weight, and our default editor is nano.

I re-ran this check with my original message and Bcc'd everyone who came
up as providing editor (using grep-aptavail).  I didn't include the list
in one of the bug messages but probably should have.

Jonathan Nieder <jrnieder@gmail.com> writes:

This isn't a change -- that was already the language from the paragraph
above:

    Thus, every program that launches an editor or pager must use the
    EDITOR or PAGER environment variable to determine the editor or pager
    the user wishes to use. If these variables are not set, the programs
    ``/usr/bin/editor`` and ``/usr/bin/pager`` should be used,
    respectively.

So in theory git has a (non-RC) bug for using editor and not
/usr/bin/editor.  (If you think that's wrong, that's probably a separate
bug; I can see it both ways, depending on how much you want to trust the
PATH.)

I tried to address that by saying that the program can just fail.  In
other words, do whatever you would do when the system() or execv() call
fails for some other reason.

Nano is priority important which means it will be installed by default
and someone who explicitly uninstalls nano will probably also install
another editor. I doubt a dependency on editor will make any
difference in practice.

Kind regards,

Jeroen Dekkers

add complexity then it's better to just keep the virtual package.

I maintain 'vis', which Provides 'editor', and I prepared a new version
where this is not done anymore, but I still have to publish it. Is this
issue to be considered as settled? I see that 'nano' already dropped its
Provides line, so I guess it is.

Paride

Paride Legovini <pl@ninthfloor.org> writes:

On the technical front, I think keeping the editor virtual package as it's
currently (occasionally) used is not really viable, because it doesn't
have well-defined behavior.  Depending directly on a virtual package that
provides as wildly varying functionality as editor does results in
essentially random experience for users if the dependency is ever used.

We had a long discussion about this over MTAs, and I think if we want to
keep the editor virtual package structure, we would need to add
default-editor just so that we can get reliable and predictable behavior,
similar to what we did with default-mta.  We could, of course, do that;
the question is whether it's worth it.

Of course, dropping the virtual package also gives us predictable
behavior, just in a different way, and with a risk that editor won't exist
on minimal installations that don't include important packages.  (My patch
assumes that we're okay with that risk, given how editors are normally
used.)

Ideally I'd like myon to feel comfortable with this proposed outcome, and
the proposed wording hasn't gotten enough seconds yet.

Re: Russ Allbery 2017-08-30 <87k21lj7id.fsf@hope.eyrie.org>

Is that true? Invoking "editor $filename" works, and that's what
expected user interface is. It is true that there's two not-quite
orthogonal systems in action here, /etc/alternatives/editor and
/usr/bin/sensible-editor, but that doesn't mean that the existing
"editor" virtual package needs to be removed.

The problem with MTAs is that only one can be installed at a time, so
it really makes a difference which one is installed. With editors,
several can be installed, and things will still Just Work.

Again, the fact that apt doesn't easily allow to predict which
alternative is chosen shouldn't mean the "editor" virtual package is
bad. It is still useful, apt frontends can let the user choose which
editor they want installed. (In practice, we don't really need a
default-editor package to make the result predictable, because "nano"
should be there as part of the base system. (While base doesn't have
any MTA.))

Even if the outcome is that "editor" isn't an official virtual package
anymore, does that really mean that packages should stop announcing
it?

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?

Christoph

Re-adding Jordi to this thread as the maintainer of GNU nano.

Christoph Berg <myon@debian.org> writes:

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.

Re: Russ Allbery 2017-12-26 <87wp1as3na.fsf@hope.eyrie.org>

I agree that the status quo is suboptimal. My concern is merely that
we shouldn't end up tearing a half-working system down just because (?)
properly fixing it is more work than tearing it down.

Provided that I'm not going to be the one doing the work, I won't
object to whatever solution is picked. Please go ahead!

Merry Christmas,
Christoph

looking at these three options for "for doing the best solution" I
think we should go for 2 or maybe 3, but then I think it's a sensible
thing to depend on, so I would say we should go with option 2.

I"m also very fine with this resulting in some trivial bugs being filed.

Hey there,

Sorry, I was on offline vacation until now. :)

El dt 26 de 12 de 2017 a les 15:24 +0000, en/na Holger Levsen va
escriure:

I personally would go with 2 as well, even if there's some trivial work
to do to get all editors to adapt. I think the editor virtual package
adds some value and completing coverage of all package should be easy
and completion can be encouraged via a release goal or something
similar.

Let me know what the outcome is and I'll adapt nano right away.

Jordi

Russ Allbery dijo [Mon, Dec 25, 2017 at 05:02:01PM -0800]:

I lean towards version 2. Yes, several packages will be buggy - but,
as you mention, not RC-buggy. It's not *that* many packages. And it's
the correct solution.

Of course, I was not familiar with this bug, and am replying just
after skimming it (trying to follow the most salient details), so this
should just be read as a "leaning towards" and not as an "endorsement"
for the patch in question.

Russ Allbery <rra@debian.org> writes:

When I let the ball drop on this three years ago, there was a consensus
that this option was the way to go.  Picking this up again, here is a
proposed Policy change to document the editor and default-editor virtual
packages.

Note that this would make quite a few packages buggy (but not RC-buggy)
since they don't Provide: editor although they participate in the
/usr/bin/editor alternative.  This was considered reasonable since it
would be cleaning up the dependency structure and the bug is fairly minor
and can be dealt with when those maintainers have a chance.

I'm looking for seconds for this diff.  It documents the status quo for
/usr/bin/pager; if we want to make a similar cleanup there, we can do that
as a separate bug.

Hello,

Well, as you might guess, I prefer the "very hard" and "make use of"
wording, but nevertheless: seconded :)  Thank you for the patch.

Hi!

I also agree that this is the way to go.

I'm not completely clear on the specific Policy nuances of some words.
Is your choice to use "should" instead of "must" when talking about
dependencies exactly to avoid creating RC bugs, or is it there any other
reason for using such weak language?

If it's the former, then fine, but I'd like to already consider turning
a few of them as "must" some years down the road, as leaving this as a
"should" will not change much from the status quo: i.e. things still
won't be able to assume that the system is in a status as described by
Policy.

Inline the "should"s that I believe should be "must"s.
                                                                    ↑↑↑↑↑↑
                                                             ↑↑↑↑↑↑

(incidentally, what's the procedure to decide on what is the "default
editor"?)
             ↑↑↑↑↑↑
           ↑↑↑↑↑↑
(really, sensible-utils has been around for ages already.  I also seem
to remember some kind of MBF to add missing dependencies.  Aren't we
ready to make this a "must" already?)

Can't this note be attached to "Programs may assume that
``/usr/bin/pager`` is available" above, to make clear that the base
already has a `pager`?  (which is… `more`, right?  what can we do to
change that again? :P)

Hi,

I concours with this but the behavior of editor should be safe.

I think we must document that is an editor in sense of posix

I can carry an editor man pages on sensible-utils and it will be nice to have an common ABI

To ensure safe behavior, the editor should:

    Avoid destructive operations unless explicitly requested

    Handle signals gracefully (e.g., SIGINT, SIGHUP)

    Not hang or fork indefinitely when invoked non-interactively

    Avoid launching graphical interfaces unless explicitly configured

Morevover it will be nice to specify that is the behavior to get line column.

I suggest something like for editor

editor [options] [--] +line:column file

and ignore options that are not supported by current editor

Moreover editor should return 126 is TERM is not supported

Last but not least we must specify that editor will run sensible-terminal-emulator or terminal-emulator if the editor does not support X/wayland.

rouca

Le jeudi 21 août 2025, 19:12:57 heure d’été d’Europe centrale Bastien Roucaries a écrit :
Hi

I propose this kind of man pages

I can ship on sensible utils if needed

rouca

Hello,

Thanks.  Let's see if others would like to review the specific proposals
you've made here.

Le vendredi 22 août 2025, 11:05:02 heure d’été d’Europe centrale Sean Whitton a écrit :
Better use TERMINAL_EMULATOR for setting the needed terminal less work because sensible-terminal use it