Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 388093 - sys-apps/portage: [ebuild F ] flag: print fetch instructions at earliest opportunity
Summary: sys-apps/portage: [ebuild F ] flag: print fetch instructions at earliest oppo...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 389065 (view as bug list)
Depends on: 388259
Blocks: 377365
  Show dependency tree
 
Reported: 2011-10-22 10:42 UTC by Hanno Zysik (geki)
Modified: 2016-05-28 22:34 UTC (History)
1 user (show)

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 Hanno Zysik (geki) 2011-10-22 10:42:34 UTC
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. ;-)
Comment 1 Zac Medico gentoo-dev 2011-10-23 19:12:02 UTC
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.
Comment 2 Zac Medico gentoo-dev 2011-10-23 19:20:16 UTC
(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.
Comment 3 Hanno Zysik (geki) 2011-10-23 20:11:38 UTC
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.
Comment 4 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2011-11-01 08:30:10 UTC
*** Bug 389065 has been marked as a duplicate of this bug. ***
Comment 5 Sergey S. Starikoff 2011-11-01 11:21:19 UTC
(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).
Comment 6 Hanno Zysik (geki) 2016-05-28 22:14:08 UTC
AFAICT this is fixed.