The feature probably is good but it's not about having alternative editor. nano and less was in stage3 from beginning, nano is easiest for new-comers(as rh1 stated before, many gentoo documentation pages mentioned nano), imagine a confusion about having emacs? So, stage3 MUST provide some basic editor by default. btw, that's why less is added into portage dependencies because of that new feature (it's a default editor for etc-update and dispatch-conf)._________________http://www.funtoo.org

If I remove nano, will my gentoo work?
Or how to tell depclean to leave it be?

Gentoo doesn't "need" nano but if vim breaks, you'll probably wish you had it installed. It barely takes up any room and doesn't depend on much. In order to keep just run 'emerge --noreplace nano' which will add it to your world file.

I think the best, simplest solution is to give virtual/editor a 'nano' USE flag which is enabled by default, that would make virtual/editor depend on app-editors/nano. That way, a user can chose to remove nano from the system which having to jump through hoops, but a less experienced user won't accidentally nuke their only CLI editor when VIM gets broken by X related borkage or something, and we don't have --depclean scaring people.

--depclean tells you to be very cautious when running it. It really means what it says.

It also gives you the following message, which tells you exactly what to do to work around this very issue;

Code:

* Always study the list of packages to be cleaned for any obvious
* mistakes. Packages that are part of the world set will always
* be kept. They can be manually added to this set with
* `emerge --noreplace <atom>`. Packages that are listed in
* package.provided (see portage(5)) will be removed by
* depclean, even if they are part of the world set.

--depclean tells you to be very cautious when running it. It really means what it says.

It also gives you the following message, which tells you exactly what to do to work around this very issue;

Code:

* Always study the list of packages to be cleaned for any obvious
* mistakes. Packages that are part of the world set will always
* be kept. They can be manually added to this set with
* `emerge --noreplace <atom>`. Packages that are listed in
* package.provided (see portage(5)) will be removed by
* depclean, even if they are part of the world set.

Being able to work around broken behavior doesn't make it any less broken, a lot of things will break when nano goes and saying "depclean has always been dangerous" is no excuse in this instance as it refuses to unmerge other system packages that are in use (as nano will be for 99% of the people that will get this message):

Code:

* Not unmerging package dev-lang/python-2.6.6-r1 since there is no valid
* reason for Portage to unmerge currently used Python interpreter.

but there is for the currently used editor (since there is no way to pick another system wide default editor)?

Putting nano in world by default would do the trick or adding a eselect setting for $EDITOR (with nano as default). The few people that want to be rid of it can, and the rest of the world can just go on as they have been for the past 10years.

Bottomline: the current behavior is broken._________________Fvwm|Fvwm forum

Being able to work around broken behavior doesn't make it any less broken, a lot of things will break when nano goes and saying "depclean has always been dangerous" is no excuse in this instance as it refuses to unmerge other system packages that are in use (as nano will be for 99% of the people that will get this message):

Code:

* Not unmerging package dev-lang/python-2.6.6-r1 since there is no valid
* reason for Portage to unmerge currently used Python interpreter.

but there is for the currently used editor (since there is no way to pick another system wide default editor)?

Putting nano in world by default would do the trick or adding a eselect setting for $EDITOR (with nano as default). The few people that want to be rid of it can, and the rest of the world can just go on as they have been for the past 10years.

Bottomline: the current behavior is broken.

I think your definition of "broken" and mine are rather different, nano will only be removed if the user chooses to install a compatible console text editor, something which is not likely to be pulled in incidentally.

The only thing which could be broken by this is the current value of the EDITOR environment variable itself, and if this is broken by the removal of nano it'll be because another editor which can satisfy this variable has been installed by the user, and anyone who uses software depending on the editor variable should be more than capable of setting it to the new software, and if nano is what they really wanted but (foolishly) let depclean remove it anyways, there's nothing stopping them from simply re-emerging it.
Unlike your python example, unmerging nano will in no way prevent the re-emerging of it...

Bottomline: the current behavior is a change from what we're used to and is less than ideal, but whether or not it can be considered "broken" is at the very least debatable, and I for one wouldn't consider it so._________________"You have to invite me in"

Recently noticing this because sys-apps/ed was installed as a dep for a net-misc/curl update that seems to have some .ed patches(?). . .

Nano is my only editor (and anyone else that has never installed an editor) so it seem a bit dumb to be warning me about a removing a package that's in my system profile. It would be like depclean removing something in the world file because I had two packages that did the same thing. It's there for a reason, let those who install their own virtual/editor remove the unused editor or unused anything duplicated that is a virtual dep.

System profile packages need protection from automated tasks like depclean instead of just a shiny warning about it._________________#gentoo-kde on freenode

No, I know exactly what is going on, the system editor is being removed even though it's known to be installed by the system and not the user. I don't care how many people don't like nano or if there is a simple user solution to make nano stick.

A system tool is being removed by a another system tool used for routine maintenance, and in my case because of a non-user-installed package that just so happens to rank higher because it it is a package dependency.

This a bug and adding nano to the world file is just a hack but apparently acceptable by those who have a say and likely use other editors which waste average users time with complexity that is not needed for 99% of normal system edits._________________#gentoo-kde on freenode

Well, if nano is to be removed from the stage 3 then the installation docs need
to be rewritten in terms of whatever is the new default editor - or all editors,
if there's no default. Any devs willing to volunteer? (It comes under the
"you broke it, you fix it" rule.)

As far as the Stage3 goes, nano isn't going anywhere. It takes a thorough read of this thread to see what's going on.

The summary is that the system set now contains some virtuals, in particular virtual/editor and virtual/pager, in place of some explicit packages, respectively app-editors/nano and sys-apps/less. Now, nano and less are installed in the Stage3 tarball (thus the dependencies of the virtuals are met) but not part of the world set. For dependency resolution, Portage's prefers dependencies that are part of the world set so, for instance, as soon as you make another editor that will satisfy virtual/editor part of your world set, nano becomes eligible for deletion by "emerge --depclean". If you want to keep it, make it part of your world set:

Code:

emerge --noreplace nano

That's what's going on. There's been a fair amount of discussion: some people like the new behavior (I do); some don't. But the bottom line (I believe) is that this small paradigm shift has no real detrimental effect and, especially since it's behaving as intended, hasn't broken anything.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

Probably already said but I know the issue I had on systems was that something else that qualified as an editor was pulled in as a direct dependency and this change meant that even if nano was the virtual/editor it no longer mattered because that relationship as "the one" isn't static.

There's also something to say if you're going to install a system with one editor then that should exist till removed and not swing to the side of the very advanced people that want to use a very advanced editor that is pointless for 99% of system edits. I'll say it was a clever way to work around the opposing views too by making this an issue of virtuals and dependencies._________________#gentoo-kde on freenode

Wouldn't it be an interesting feature to put some USE flag options in those virtual packages? I mean, I could select my favorite editor in an easy way, with a simple USE="emacs vim -nano". It could happen the same with pager with USE="less -more"

I think that every distribution must have a quaranteed set of basic tools. Basic editor (one may argue which one, nano is as good as any for the role) is one
of basic tools. This, I think, is a role of @system and it is not a place for virtuals.