Noticed on two ebuilds when ran full emirrordist: $ emirrordist --verbose --mirror --tries 1 --repo gentoo --distfiles $(portageq envvar DISTDIR) [INFO] failure: games-action/descent1-data-1.4a setup_descent_1.4a_(16596).exe no fetchable uris [INFO] failure: games-action/descent2-data-1.2 setup_descent_2_1.1_(16596).exe no fetchable uris AFAIU normally these would be fixed by RESTRICT="fetch mirror". Ebuilds have the following: $ cat descent1-data-1.4a.ebuild MY_EXE="setup_descent_1.4a_(16596).exe" SRC_URI="cdinstall? ( http://www.dxx-rebirth.com/download/dxx/misc/descent-game-content-10to14a-patch.zip ) !cdinstall? ( ${MY_EXE} )" RESTRICT="bindist !cdinstall? ( fetch )" $ cat descent2-data-1.2.ebuild MY_PATCH="http://www.dxx-rebirth.com/download/dxx/misc/d2xptch12.tgz" MY_EXE="setup_descent_2_1.1_(16596).exe" SRC_URI="cdinstall? ( ${MY_PATCH} ) !cdinstall? ( ${MY_EXE} )" RESTRICT="bindist !cdinstall? ( fetch )" Adding "mirror" into RESTRICT under USE-condition does not help. Is it an ebuild bug or emirrordist bug?
The SRC_URI evaluation is oversimplified, it uses use_reduce with matchall=True like this: > >>> use_reduce('cdinstall? ( http://www.dxx-rebirth.com/download/dxx/misc/descent-game-content-10to14a-patch.zip ) !cdinstall? ( setup_descent_1.4a_(16596).exe )', uselist=None, matchall=True, eapi='6') > ['http://www.dxx-rebirth.com/download/dxx/misc/descent-game-content-10to14a-patch.zip', 'setup_descent_1.4a_(16596).exe'] We make it loop through all combinations of states for the USE flags found in RESTRICT, and evaluate SRC_URI only for those combinations where fetch is not restricted.
The number of USE combinations could be prohibitively large in some cases (see bug 374397 for example), so in those cases we'll fallback to the matchall behavior.