• Bug#682347: mark 'editor' virtual package name as obsolete

    From Russ Allbery@21:1/5 to Artem Leshchev on Thu Aug 24 09:10:02 2017
    XPost: linux.debian.bugs.dist

    Control: tags -1 patch

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

    Artem Leshchev <wolf@gwerewolf.ru> writes:

    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?

    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
  • From Russ Allbery@21:1/5 to Brendan O'Dea on Thu Aug 24 19:40:02 2017
    XPost: linux.debian.bugs.dist

    Dropping Artem, whose email address no longer works.

    Brendan O'Dea <bod@debian.org> writes:
    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
    [...]

    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

    --
    Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christoph Berg@21:1/5 to All on Thu Aug 24 20:30:02 2017
    XPost: linux.debian.bugs.dist

    Re: To Russ Allbery 2017-08-24 <20170824171653.r24gyar5mikyje7q@msg.df7cb.de>
    $ 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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Brendan O'Dea@21:1/5 to Russ Allbery on Thu Aug 24 12:30:02 2017
    XPost: linux.debian.bugs.dist

    On Wed, Aug 23, 2017 at 11:03:23PM -0700, Russ Allbery wrote:
    Would anyone on the Policy list or any of the maintainers bcc'd want to
    make a case for keeping the virtual package "editor"?

    No strong objection to removing this virtual package.

    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
    [...]

    --bod

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Nieder@21:1/5 to Russ Allbery on Fri Aug 25 00:00:02 2017
    XPost: linux.debian.bugs.dist

    Hi,

    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.

    [...]
    @@ -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.
    -

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Christoph Berg on Fri Aug 25 01:00:02 2017
    XPost: linux.debian.bugs.dist

    Christoph Berg <myon@debian.org> writes:

    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.

    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.

    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):

    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.

    --
    Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Jonathan Nieder on Fri Aug 25 01:00:02 2017
    XPost: linux.debian.bugs.dist

    Jonathan Nieder <jrnieder@gmail.com> writes:
    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.

    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.)

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

    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.

    --
    Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Dekkers@21:1/5 to Christoph Berg on Fri Aug 25 11:40:02 2017
    XPost: linux.debian.bugs.dist

    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.

    Kind regards,

    Jeroen Dekkers

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paride Legovini@21:1/5 to jeroen@dekkers.ch on Wed Aug 30 15:00:01 2017
    XPost: linux.debian.bugs.dist

    On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers <jeroen@dekkers.ch> wrote:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Paride Legovini on Wed Aug 30 20:30:02 2017
    XPost: linux.debian.bugs.dist

    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.

    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.)

    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.

    --
    Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christoph Berg@21:1/5 to All on Wed Sep 6 10:40:02 2017
    XPost: linux.debian.bugs.dist

    Re: Russ Allbery 2017-08-30 <87k21lj7id.fsf@hope.eyrie.org>
    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.

    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.

    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.

    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.))

    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.

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

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

    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAlmvovUACgkQTFprqxLS p6518xAAlRXG/4y7pFVdbh0rqo5mLjiMQHutkl2tNrP2gqVx8hIQFYDsj4c5esj1 cGV4pLXkW0LLqnrt6wCZTYik5Mf43jstvEX2Cv9FqQrGa/79TXtfpq8qpplEAvVG 1Kg6GqShZ2LRK/wDAT15XDy9F5luP8w+BddqBf6ltwCcPYbs5RcmmadPTLJlwe8A u0tEFBvztDi4pBUnj8LqVAudhAZDSdUlSblUcpahJGW0GNOruBWXY/tlYVxwNO98 +DKJoijnzfB7NWOsXGW8As56Ranm/239/6Uz+18nuwrxvoU/acPqcU1afvvQHlKh q1vB60YHFQ7ab94618XYkd4lrwG3BAz/floO9Hla9J4/wC7KhWU+3JdM61989rWl vuMMSkwzEtuqixv2a0lJ68x2VS9kl4SqdU/7cFAhMRH9N+L5doVmPJVI2KTbBFcZ 72hotvJtPKmh7Uib0RBJHfkblfddSZC+vJAgM7nJAmEQaC39jHKXGMMPApTerM83 klEq+abXsUXK6JN2Sb5MdgvkwGsj4UHOfYgb2WoJXujZwHMxteZxlMFuFdDFFM1P /AycTWAnhXSmQXBU/a6L1S2p9dsTkdxYeUsvwPPAZJH6CCMySfw+wTmB08RNSES8 M2ITP00e4kjws6JpHsZEsntOneAB7yYM/6qipy8+WcXDFLSJfP8=
    =GyA+
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)