Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 153761 - emerge should fail immediately on unsatisfied fetch restriction
Summary: emerge should fail immediately on unsatisfied fetch restriction
Status: RESOLVED DUPLICATE of bug 151113
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-01 16:21 UTC by Wesley Pegden
Modified: 2006-11-03 02:24 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wesley Pegden 2006-11-01 16:21:28 UTC
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.
Comment 1 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-11-01 18:39:53 UTC
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.
Comment 2 Zac Medico gentoo-dev 2006-11-01 19:00:08 UTC
This is related to bug 151113.  If the files haven't already been fetched, a fetch restricted ebuild effectively becomes a RESTRICT=unattended ebuild.
Comment 3 Wesley Pegden 2006-11-01 19:39:02 UTC
> 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?  
Comment 4 Wesley Pegden 2006-11-01 19:43:51 UTC
(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.
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2006-11-02 16:29:13 UTC
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.
Comment 6 Zac Medico gentoo-dev 2006-11-03 00:11:00 UTC
(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.
Comment 7 Zac Medico gentoo-dev 2006-11-03 02:23:40 UTC
I think this is close enough to bug 151113 to mark as a duplicate...
Comment 8 Zac Medico gentoo-dev 2006-11-03 02:24:00 UTC

*** This bug has been marked as a duplicate of 151113 ***