After typing "emerge moo", emerge successfully prints the expected output and then tries to resolve dependencies for "moo". If this is the only requested 'action', I think it's safe to return from that point (since there is no "moo" package in the tree and would be pointless to have this output if there is one). I attached a trivial patch also. Reproducible: Always
Created attachment 291741 [details, diff] the output of git --diff
Created attachment 291745 [details, diff] the output of git --diff Make it consider multiple "moo"s
(In reply to comment #0) > If this is the only requested > 'action', I think it's safe to return from that point (since there is no "moo" > package in the tree and would be pointless to have this output if there is > one). If we do that, I think we should make it emerge --moo, in order to avoid possible ambiguity. Meanwhile, we can keep the existing 'emerge moo' behavior exactly as it is, and show a deprecation message which suggests to use emerge --moo instead.
(In reply to comment #3) > If we do that, I think we should make it emerge --moo, in order to avoid > possible ambiguity. Meanwhile, we can keep the existing 'emerge moo' behavior > exactly as it is, and show a deprecation message which suggests to use emerge > --moo instead. I think that's the way to go.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9929eaf3e50897c814062bec5a704898e085d048
Should I close this bug then?
Let's keep it open until it's released.
This is fixed in 2.1.10.33 and 2.2.0_alpha73.