Feel free to change the assignment to others. I'm not sure if the metadata is correct in this case. The addition of sys-apps/busybox to virtual/editor is not a good solution. While it is a valid editor, I agree, it has at least three flaws with it being in virtual/editor and they are all concerning the fact that busybox is in @system. 1) There is no need to have an editor explicitly listed in the world file because virtual/editor is in the @system set. This means that a --depclean will remove the user's editor. 2) The addition of busybox makes ROOT=foo emerge -e system diverge *away* from default stage3 installations (because there is no nano installed) 3) busybox is for power users, a person new to Linux will not know about "busybox vi <file>" - We should strive to be friendly to new users.
It can be replaced by app-admin/eselect-vi (while this does not depend on any implementation, there will always be the busybox one, as it is in system set).
(In reply to comment #1) > It can be replaced by app-admin/eselect-vi (while this does not depend on any > implementation, there will always be the busybox one, as it is in system set). That wouldn't help, because busybox doesn't call eselect-vi, so the symlink doesn't get set without user interaction. I also think that it's conceptually wrong to have eselect modules in virtual/editor. 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. Alternative solution: Add a "vi-symlink" USE flag to sys-apps/busybox, depend on "vi-symlink? ( app-admin/eselect-vi )" and call "use vi-symlink && eselect vi update --if-unset" in pkg_post{inst,rm}. Then virtual/editor could depend on "sys-apps/busybox[vi-symlink]". (But IMHO, that would be a lot of effort for very little return.) Reassigning to emacs (de-facto maintainers of virtual/editor) and adding embedded (busybox maintainers) to CC.
I've removed busybox from the dependencies of virtual/editor.
