The "mirrorselect" tool needs the "which" tool to check for additional dependencies. Without it, it will display a misleading error message. To prevent this, it is probably useful to add the dependency to the ebuild, so the tool won't get called without "which" installed. Proposed patch for mirrorselect-1.2.ebuild follows. --- /tmp/a 2007-08-21 02:44:35.000000000 +0000 +++ /tmp/b 2007-08-21 02:44:58.000000000 +0000 @@ -12,7 +12,8 @@ IUSE="" RDEPEND=">=dev-util/dialog-0.7 - net-analyzer/netselect" + net-analyzer/netselect + sys-apps/which" S=${WORKDIR} Reproducible: Always Steps to Reproduce: 1. emerge --unmerge sys-apps/which 2. emerge mirrorselect 3. mirrorselect -s4 -o -D
(In reply to comment #0) > 1. emerge --unmerge sys-apps/which Don't unmerge packages that are part of system (grep sys-apps/which /usr/portage/profiles/base/packages).
So system packages don't get recorded as dependencies, right? I still think this issue has some relevancy, as it makes sense to run mirrorselect early when compiling packages from system. But with the current architecture this is probably more of a documentation issue.
In addition, if you do a stage1 install you don't get `which` installed, so perhaps having it as a dependency would be nice. Also mirrorselect needs something like `wget`, `fetch` or `curl` as a dependency as I have to also install one during a stage1 install as they are not pulled in.
http://devmanual.gentoo.org/general-concepts/dependencies states that unless there are specific version restrictions, no package outside of system should explicitly define a R?DEPEND on a package in the system target. As for stage 1 and 2 installs, well, there's a reason they're unsupported. Actually mirrorselect is the least of your problems, because it's not critical that you set custom mirrors during the install. As far as I'm concerned this does not appear to be a valid bug.
(In reply to comment #4) > http://devmanual.gentoo.org/general-concepts/dependencies states that unless > there are specific version restrictions, no package outside of system should > explicitly define a R?DEPEND on a package in the system target. > Ok, this makes sense. So the proposed fix is probably not appropriate. Rather than adding a dependency, patching mirrorselect to check for which in $PATH could make sense, so users won't get misleading error messages (maybe already done, haven't looked into mirrorselect lately). It just seems weird that mirrorselect does take into account that download tools may be missing, but does not handle the case when which is missing. > As for stage 1 and 2 installs, well, there's a reason they're unsupported. > Actually mirrorselect is the least of your problems, because it's not critical > that you set custom mirrors during the install. > It's not critical, but it's not all that improbable that someone tries to do that provided that the gentoo documentation mentions the possibility. Stage 1 and 2 may be unsupported, but it may be argued that it's still useful to make stage 1 and 2 more robust by reducing the possibility of running into problems. > As far as I'm concerned this does not appear to be a valid bug. > I agree that it belongs to mirrorselect, not to portage.
Created attachment 144944 [details, diff] mirrorselect-1.3_no_which.patch Replaces 'which' call with python internal function. --untested-- It looks correct, but I didn't have time to test it -- please test.
Thanks, this is fixed in mirrorselect-1.4.
