Currently, if you emerge a bunch of packages (say a few hundred because this is a new install), portage may fail partway through the list due to a fetch restriction on a package (for example, your java documentation!!! argghh!). Of course, wary users can avoid this problem by checking the output of emerge -p [packages] for any unsatisfied fetch restrictions. However, it seems the default behavior of portage should be to immediately exit and print an error message if asked to emerge a package (or a package with a dependency) which has an unsatisfied fetch restriction. Ideally, it should print the list of packages with unsatisfied fetch restrictions and the pkg_nofetch() output for each one.
I'd prefer uses follow the recommendations and look at the -p output prior to doing things like installing hundreds of packages. The output is there for you to look at (and to correct any errors like incorrect versions and to fetch fetch restricted things). Doing an emerge with a fetch restricted package is sensible if you: a) Expect the merge to currently fail there, or b) fire off the merge but fetch the missing restricted files prior to the restricted package's merge phase. This is akin to the post-depend built_with_use checks that people want us to die with. I'd again say no; the output you are looking for is (mostly) in the pretend output of emerge. Use it.
This is related to bug 151113. If the files haven't already been fetched, a fetch restricted ebuild effectively becomes a RESTRICT=unattended ebuild.
> Doing an emerge with a fetch restricted package is sensible if you: > a) Expect the merge to currently fail there, or > b) fire off the merge but fetch the missing restricted files prior to the > restricted package's merge phase. Of course I agree that these are legitimate reasons to emerge with an unsatisfied fetch restriction, so there should be an option to override this behavior. That said, I would wager that the majority of times people run an emerge command with an unsatisfied fetch restriction it is unintentional, justifying making the default behavior an upfront error message or warning (it could warn the user and ask if it should proceed). Of course, as you and I both have said, an attentive user will notice the small red F next to a package name in the output of emerge -p and satisfy the fetch restriction (although, to do this, it seems to me they'll have to either wait till it fails or manually look in the ebuild file for the url and destination name of the file). However, I would argue that by changing the default behavior as I have suggested would make portage more usable, less of a headache (especially for users learning the ropes with a new install) without sacrificing flexibility, so long as there is the possibility for override. Right now, this is how portage handles the situation with blocked packages---it tells you up front if you have package block problems and fails, rather than waiting to tell you once it's crapped out halfway through. That information is also in the output of pretend emerge, so you would be "justified" in punishing users that fail to check for package block problems as well. But why is that better?
(In reply to comment #2) > This is related to bug 151113. If the files haven't already been fetched, a > fetch restricted ebuild effectively becomes a RESTRICT=unattended ebuild. > sorry for submitting separate replies. yeah, this is basically the same problem from a usability standpoint, I guess.
If you're worried about this just run emerge -pf prior to the actual merge run. Closing as WONTFIX due to complexity/architecture issues. For this to work a large part of the fetch logic would have to be moved into the dep resolver or the visibility checker, and that's not a good thing todo IMO.
(In reply to comment #5) > For this to work a > large part of the fetch logic would have to be moved into the dep resolver or > the visibility checker, and that's not a good thing todo IMO. If you think about it, fetch restriction is often (always?) due to restrictive licenses. So, this bug is also related to bug 17367 and bug 152593.
I think this is close enough to bug 151113 to mark as a duplicate...
*** This bug has been marked as a duplicate of 151113 ***
