Bugzilla Bug 153761

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 ***