I regularly update my system using something like "emerge -uaND @world". This prints a list of packages and asks me whether to proceed. If some of the packages are using fetch restrictions, those packages will be marked with a red F accordingly, but resolving them is still a number of steps: for every such package, I'll have to "emerge -f =category/package-version", read the text and proceed accordingly. As it can be expected that I want to manually fetch files before proceeding, it would be great if "emerge --ask" could print all those fetch instructions when it prints the list of packages to emerge. Personally I'd prefer the instructions after the package list, but I'll be happy the other way round, too. In such a scenario, I could read and follow all those instructions, without having to manually run emerge for every affected package.
This is similar to bug 388093, but I hadn't thought of calling pkg_nofetch before the --ask prompt. That's a good idea.
Yeah this would be great.
Ping?
Created attachment 304975 [details, diff] Portage patch v1 OK, to get some traction here: how about the attached patch? I tried to adjust the code used by the Display class to print either a green "f" or a red "F". The thing I'm most uncertain about is whether I'm using the correct portdb object there. And the use of the underscored method _pkg_use_enabled from the depgraph object might warrant closer inspection as well. I also thought about collecting the list of packages to fetch inside the Display class, in order to avoid both code duplication and repeated computation. But that kind of mixing computation and presentation feels rather ugly, so I decided against it.
(In reply to comment #4) > I also thought about collecting the list of packages to fetch inside the > Display class, in order to avoid both code duplication and repeated > computation. But that kind of mixing computation and presentation feels > rather ugly, so I decided against it. The fetch instructions can be considered display code. So, they have to go either in the Display class or in depgraph._display_problems(). Maybe the Display class makes more sense, since the fetch instructions may not be considered a "problem", depending on how you look at it.
(In reply to comment #4) > Created attachment 304975 [details, diff] [details, diff] > Portage patch v1 > > OK, to get some traction here: how about the attached patch? action_build is just the wrong place for it, because it really needs to be into the depgraphs' display, not wrapped around it.
(In reply to comment #4) > The thing I'm most uncertain about is whether I'm using > the correct portdb object there. There's a different portdb for each $ROOT, so you have to get the instance that belongs to the given package. You can git it like this: portdb = pkg.root_config.trees['porttree'].dbapi
Created attachment 305033 [details, diff] Portage patch v2 (In reply to comment #5) > Maybe the Display class makes more sense, OK, moved stuff there. I changed the API of set_pkg_info, but don't expect anyone else to be using that. No part of the portage source code uses it, except for the call I changed to match. (In reply to comment #7) > There's a different portdb for each $ROOT, so you have to get the instance > that belongs to the given package. You can git it like this: > > portdb = pkg.root_config.trees['porttree'].dbapi I've used a slightly different form, to keep all such phrases in the class the same. Display does it like this: portdb = self.conf.trees[pkg.root]["porttree"].dbapi If there is any benefit to the former method, it should be changed consistently.
Thanks, this is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=970ab392337a0584c9a329c55c58e3b930ae4af1
This is in 2.2.0_alpha91, but I'll leave this bug open until it's in an unmasked release.
This is fixed in 2.1.10.50.
