While ed is technically an editor, it's not a great one (I certainly don't know anybody that uses it). sys-devel/bc-1.07.1-r1 (currently unstable) pulls in ed as a build dependency, and since our kernel sources packages pull in bc because it's needed for kernel compilation, once a user installs a kernel sources package, portage is happy to get rid of nano because ed satisfies the virtual. While users can put nano in their world file, from a support perspective this is not desirable. Please remove ed from virtual/editor.
The criteria for adding a provider are listed in a comment in the virtual: # Add a package to RDEPEND only if the editor: # - can edit ordinary text files, # - works on the console. sys-apps/ed fulfils both, so it's there. I think we cannot base the list on subjective criteria (adding only "great" editors would mean keeping only Emacs and removing all others ;) or on personal preferences. (In reply to dwfreed from comment #0) > While users can put nano in their world file, from a support perspective > this is not desirable. But that's precisely what they should do. If they want nano then they should have nano in their world file (and similar for Emacs or Vim). The virtual only guarantees that they get any editor.
How is this different from bug 309147?
The difference between ed and the other providers of virtual/editor is that all of the other providers (except nano, which comes in our stage3s) are installed by the user's choice. ed is installed because it is a build dependency of bc-1.07.1-r1, which is a "runtime" dependency of all of our kernel sources (this was done because kernel compilation requires bc). darkside's point 1 and 3 from bug 309147 apply here. For users that want ed as their editor, the following quote from bug 309147 comment 2 (ironically made by ulm) applies (replace busybox/bb with ed): > We should simply remove busybox from the virtual. Advanced users that want bb as > their only editor can put virtual/editor in their package.provided.
(In reply to dwfreed from comment #3) > ed is installed because it is a build dependency of bc-1.07.1-r1, which is > a "runtime" dependency of all of our kernel sources [...] We cannot remove providers from the virtual because of random reverse dependencies. That would mean to also remove emacs and vim, for example. > darkside's point 1 and 3 from bug 309147 apply here. Busybox is a very different case, because it is not a dedicated editor package. Also it comes with its own config file outside of USE flags, so you can install it without any editor function, in which case the user could end up without any editor on the system. Besides, Portage has double safety here. It will emit an extra warning if you try to unmerge nano (IIUC, it will warn about the first provider of a virtual in the system set): # emerge -Cp app-editors/nano * This action can remove important packages! In order to be safer, use * `emerge -pv --depclean <atom>` to check for reverse dependencies before * removing packages. >>> These are the packages that would be unmerged: !!! 'app-editors/nano' (virtual/editor) is part of your system profile. !!! Unmerging it may be damaging to your system. app-editors/nano selected: 2.9.6 protected: none omitted: none All selected packages: =app-editors/nano-2.9.6 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. *** This bug has been marked as a duplicate of bug 600910 ***
I very strongly disagree with this bug resolution. This is going to be a huge user-facing issue. There is close to zero value in keeping sys-apps/ed in virtual/editor. It's there on a technicality. Who is this hypothetical user who actually wants ed as his primary editor? There are going to be dozens to hundreds of REAL users affected by the nano depclean in the near future. The "extra warning" you mention is bug 375115, it only happens by accident. Please reconsider this. If you remove ed, it will negatively affect approximately 0 users, and there are known workarounds for this advanced users. It will positively affect everyone else.
(In reply to Ben Kohler from comment #5) > I very strongly disagree with this bug resolution. This is going to be a > huge user-facing issue. There is close to zero value in keeping sys-apps/ed > in virtual/editor. It's there on a technicality. > > Who is this hypothetical user who actually wants ed as his primary editor? > There are going to be dozens to hundreds of REAL users affected by the nano > depclean in the near future. > Who knows, some people are strange, I know people who live with either sed or ed daily, so yes, these people exists.
We should fit our defaults to the normal user, especially the new user. This is important, please stop closing this bug just because "technically" ed belongs to be there. This is not about being technically correct/incorrect, but a sane behavior for our users.
(In reply to Ben Kohler from comment #7) > We should fit our defaults to the normal user, especially the new user. > > This is important, please stop closing this bug just because "technically" > ed belongs to be there. This is not about being technically > correct/incorrect, but a sane behavior for our users. Gentoo is about choice, sanity control is being performed by the creature at the computer. No more no less.
(In reply to Ulrich Müller from comment #1) > But that's precisely what they should do. If they want nano then they should > have nano in their world file (and similar for Emacs or Vim). The virtual > only guarantees that they get any editor. ed is not an editor, despite what its man page says. End of story. Every other editor in the list at least shows the file contents upon start, ed doesn't even do that... Please be sensible. Things aren't about technical correctness. We'd have sed and coreutils (for cat + echo + whatever other tools) in there too then to be technically correct. It's also the very last choice in the list, added for some sort of odd reasons whatever amount of decades ago. Also don't forget that Gentoo is about choices. My choice is to avoid headaches to myself and to our users. My choice is to not lose users over nonsensical "technically correct" decisions in a virtual provider package that is about editors for mostly normal users, put into @system in order to be able to edit a make.conf file. No-one does that with ed, except one person zlogene claims to know.
virtual/editor is also about having something for the EDITOR environment variable. I invite you to use git with it set to 'ed', then talk in favor of keeping it in virtual/editor.
Read comment #4. Portage won't unmerge nano by itself, but only by explicit user interaction, and then it will show two prominent warnings. If users want ${GREAT_EDITOR} then they should put ${GREAT_EDITOR} in their world file. We shouldn't force our choice of editors onto the user by offering only a restricted subset in the virtual. This is the same situation as for virtual/pager, where we don't remove util-linux from RDEPEND, even if that package is in the system set of linux profiles.
I've invited people over to #gentoo-base in IRC to discuss this. And I asked these questions in the round: What damage would it have to remove ed from virtual/editors? And what technical benefit would keeping ed in virtual/editors have? The only reason people wanna keep ed in virtual/editors is because technically it _is_ an editor? Now please for the sake of finally coming to a conclusion in this bug, please answer these questions to the best of your knowledge. I personally vote for removing ed from virtual/editors. It's the only package from sys-apps category in the list and I doubt it was added to sys-apps because it's that great of an editor.
(In reply to Lars Wendler (Polynomial-C) from comment #12) > What damage would it have to remove ed from virtual/editors? We would restrict users' choice by imposing our personal preferences on them. That's not the Gentoo way. > [...] > It's the only package from sys-apps category in the list and I doubt it was > added to sys-apps because it's that great of an editor. I don't see how the category could be an argument here. There's sys-apps/less, does that imply that less isn't a good pager?
I also vote to remove ed from virtual/editor.
(In reply to Mike Gilbert from comment #14) > I also vote to remove ed from virtual/editor. That's all well and good, but then hand-selecting packages (based on what?) is still not a reasonable procedure. So, please come up with an update of the criteria: # Add a package to RDEPEND only if the editor: # - can edit ordinary text files, # - works on the console. For example, restricting it to screen editors could work (in which case all the providers should depend on ncurses, I guess). What certainly won't work is something like "cannot have reverse dependencies in the system set", because that would depend on profiles and use flags, and would be a maintenance nightmare.
(In reply to Ulrich Müller from comment #15) > That's all well and good, but then hand-selecting packages (based on what?) > is still not a reasonable procedure. So, please come up with an update of > the criteria: > > # Add a package to RDEPEND only if the editor: > # - can edit ordinary text files, > # - works on the console. > > For example, restricting it to screen editors could work (in which case all > the providers should depend on ncurses, I guess). > > What certainly won't work is something like "cannot have reverse > dependencies in the system set", because that would depend on profiles and > use flags, and would be a maintenance nightmare. the problem with the current rules in the package is that I would be fine to add sys-apps/sed, app-editors/hexedit, or app-editors/curses-hexedit. they are all console programs and *can* be used to edit text files. (so can dd now that i think about it). im sure we all agree that none of those *should* be in the list tho. "screen editors" or "visual editors" or "wysiwyg editors" or something is probably the right way to go. ed does not show you the file, you only write lines at a time and have to remember what was around it. the reason this is problematic comes down to if a user accidentally ends up with a system with only ed they are in for a pretty hard time to edit stuff. whereas even if you end up vim/emacs but use the other you at least can figure out whats going on. the property we care about in virtual/editor is no that it is technically possible to edit files using it, its that you can easily edit files.
I went through the list of all providers. I assume that they are display editors if their either link to sys-libs/ncurses (directly, or via sys-libs/slang). I have tested the handful that are remaining. Indeed, all providers of the virtual are display editors, except for ed. So the following additional rule would work: # - is a "display" or "visual" editor (e.g., using ncurses). However, I am still not entirely convinced that this is the right thing to do.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03e5b00b2188fbb3c36cc8c51c1c55bace2094e9 commit 03e5b00b2188fbb3c36cc8c51c1c55bace2094e9 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-05-18 06:26:14 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-05-18 06:33:48 +0000 virtual/editor: Allow only display editors as providers. If you prefer a line editor like ed when editing files with your DECwriter LA120 printing terminal :-) and don't want any newfangled display editor installed on your system, then add virtual/editor to package.provided as a workaround. Closes: https://bugs.gentoo.org/655906 Package-Manager: Portage-2.3.37, Repoman-2.3.9 virtual/editor/{editor-0.ebuild => editor-0-r1.ebuild} | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
Removed ed for now. Let's see if we get any complaints from users.
