As the summary says it, if I check what packages to update there may be packages with fetch restrictions. Now, I have to 'emerge <package>' wait for the instructions and the failure to emerge; fetch the file from the given location; start the emerge again and clean my mail notification sent on failure. That could be improved by printing the fetch instructions if portage detects the fetch restriction flag on a package and its file(s) not in DISTDIR. Then, exit gracefully. Well, just a thought. ;-)
It already calls pkg_nofetch for --fetchonly, with or without --pretend. So, what you want is for it to call pkg_nofetch in the foreground at the earliest opportunity, like we already do for pkg_pretend? That seems reasonable.
(In reply to comment #0) > That could be improved by printing the fetch instructions if portage detects > the fetch restriction flag on a package and its file(s) not in DISTDIR. Then, > exit gracefully. It doesn't exit immediately because it's possible that some of other packages in the list can fetch/install successfully (especially with --keep-going). Even without --keep-going, some people might see the [ebuild F ] in the merge list (especially with --ask) and run emerge --fetchonly in a separate terminal in order to see the pkg_nofetch output and perform the manual fetches. If they leave the original emerge invocation at the --ask prompt, they can let it continue after they've completed the manual fetches.
I surely do not want it to exit immediatly but gracefully without the error and noise I encounter. I thought that it could be handled like blockers where information is printed at the end of --pretend. Well, in that way somehow. You know best if it is possible and how it is done the best way ... It would just be most convenient for the --pretend case; maybe --ask case. I wonder if the other options should change behaviour. I guess not.
*** Bug 389065 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > I surely do not want it to exit immediatly but gracefully without the error and > noise I encounter. Why? To my mind portage should not start upgrading until in enshures, that all source becomes available (not fetched by user fetch restricted source are exactly unavailable, so until solution of fetch restriction before start we can say that emerge process will fail).
AFAICT this is fixed.
Fixed by this commit: https://gitweb.gentoo.org/proj/portage.git/commit/?id=970ab392337a0584c9a329c55c58e3b930ae4af1