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

[Artem Leshchev]

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?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

On Fri, Feb 28, 2014 at 08:57:33PM +0100, Bill Allombert wrote:
> On Sun, Jul 22, 2012 at 01:16:08AM +0400, Artem Leshchev wrote:
> > 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?
> 
> 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.

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,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Control: tags -1 patch

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

Artem Leshchev  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
 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. [#]_
+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.
 
 .. _s-web-appl:
 
@@ -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.
-
 .. [#]
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..73bbf01 100644
--- a/virtual-package-names-list.txt
+++ b/virtual-package-names-list.txt
@@ -208,10 +208,12 @@ Games and Game-related
 
 Old and obsolete virtual package names
 --
-Note, that no other package then the ones listed here should use
-these virtual package names.
+Packages should no longer reference these virtual package names.
 
-[There are currently no such package names in use]
+ editor  indicated any package providing the editor
+ alternative, removed in November 1996 because
+ this was not useful for dependencies and was
+ never used except in Provides
 
 Changelog
 -
@@ -363,3 +365,6 @@ Russ Allbery:
 virtual-mysql-server-core
 

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

[Brendan O'Dea]

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

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

[Russ Allbery]

Dropping Artem, whose email address no longer works.

Brendan O'Dea  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 (r...@debian.org)   

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

[Christoph Berg]

Re: Russ Allbery 2017-08-24 <87efs1lyc7@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.

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

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

[Christoph Berg]

Re: To Russ Allbery 2017-08-24 <20170824171653.r24gyar5mikyj...@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

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

[Jonathan Nieder]

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

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

[Russ Allbery]

Jonathan Nieder  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 (r...@debian.org)   

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

[Russ Allbery]

Christoph Berg  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 (r...@debian.org)   

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

[Jeroen Dekkers]

On Thu, 24 Aug 2017 19:16:53 +0200,
Christoph Berg wrote:
> 
> Re: Russ Allbery 2017-08-24 <87efs1lyc7@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

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

[Paride Legovini]

On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers  wrote:
> On Thu, 24 Aug 2017 19:16:53 +0200,
> Christoph Berg wrote:
> > 
> > Re: Russ Allbery 2017-08-24 <87efs1lyc7@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

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

[Russ Allbery]

Paride Legovini  writes:
> On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers  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 (r...@debian.org)   

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

[Christoph Berg]

Re: Russ Allbery 2017-08-30 <87k21lj7id@hope.eyrie.org>
> Paride Legovini  writes:
> > On Fri, 25 Aug 2017 10:09:34 +0200 Jeroen Dekkers  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


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Russ Allbery dijo [Mon, Dec 25, 2017 at 05:02:01PM -0800]:
> (...)
> 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.)
> (...)
> 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.

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.

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

[Russ Allbery]

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

Christoph Berg  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-w

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

[Christoph Berg]

Re: Russ Allbery 2017-12-26 <87wp1as3na@hope.eyrie.org>
> 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.

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

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

[Holger Levsen]

On Mon, Dec 25, 2017 at 05:02:01PM -0800, Russ Allbery wrote:
> 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. 
> 
> 3. Mark editor obsolete.

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.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

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

[Jordi Mallach]

Hey there,

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

El dt 26 de 12 de 2017 a les 15:24 +, en/na Holger Levsen va
escriure:
> On Mon, Dec 25, 2017 at 05:02:01PM -0800, Russ Allbery wrote:
> > 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. 
> > 
> > 3. Mark editor obsolete.
> 
> 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 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
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

signature.asc
Description: This is a digitally signed message part

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

[Bill Allombert]

On Sun, Jul 22, 2012 at 01:16:08AM +0400, Artem Leshchev wrote:
> 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?

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,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org