Package: debian-policy
Severity: wishlist
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?
On Wed, Aug 23, 2017 at 11:03:23PM -0700, Russ Allbery wrote:
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.
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
[...]
$ 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
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.
+++ b/policy/ch-customized-programs.rst[...]
@@ -93,19 +93,21 @@ page.
-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. [#]_
+Packages may assume that ``/usr/bin/editor`` and ``/usr/bin/pager`` are +available as fallbacks without adding an explicit package dependency, and +may fail if they are not present. There are no ``editor`` or ``pager`` +virtual packages.
@@ -572,10 +574,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.
-
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):
Russ Allbery wrote:
+++ b/policy/ch-customized-programs.rst[...]
@@ -93,19 +93,21 @@ page.
-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. [#]_
+Packages may assume that ``/usr/bin/editor`` and ``/usr/bin/pager`` are
+available as fallbacks without adding an explicit package dependency, and >> +may fail if they are not present. There are no ``editor`` or ``pager``
+virtual packages.
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?
Re: Russ Allbery 2017-08-24 <87efs1lyc7.fsf@hope.eyrie.org>
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:
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.
On Thu, 24 Aug 2017 19:16:53 +0200,
Christoph Berg wrote:
Re: Russ Allbery 2017-08-24 <87efs1lyc7.fsf@hope.eyrie.org>
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:
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.
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.
On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers <jeroen@dekkers.ch> wrote:
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.
I agree, I see no advantage in adding a default-editor: if we have to
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 Legovini <pl@ninthfloor.org> writes:
On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers <jeroen@dekkers.ch> wrote:
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.
I agree, I see no advantage in adding a default-editor: if we have to
add complexity then it's better to just keep the virtual package.
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.
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.
Ideally I'd like myon to feel comfortable with this proposed outcome, and
the proposed wording hasn't gotten enough seconds yet.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 62:10:14 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,518 |