Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 661332 - sys-apps/portage: PORTAGE_BINHOST uses package only from binhost on the right when an identical package exists in multiple binhost
Summary: sys-apps/portage: PORTAGE_BINHOST uses package only from binhost on the right...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Depends on: 668334
  Show dependency tree
Reported: 2018-07-16 16:16 UTC by Rick Farina (Zero_Chaos)
Modified: 2021-01-18 02:42 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Rick Farina (Zero_Chaos) gentoo-dev 2018-07-16 16:16:58 UTC
Add in the ability to read in a list of PORTAGE_BINHOST from either the portage variable or a user specified https location, and sort them by speed.

Output should be a properly formatted PORTAGE_BINHOST="1 2 3" sent to stdout or /etc/portage/make.conf

I tested portage with multiple mirrors in the PORTAGE_BINHOST variable, and it appears to download from the first entry.  It is advisable to write all the results in order, however, to make sure the next run of mirrorselect works as expected (since the second run would be operating using the PORTAGE_BINHOST written from the first run presumably)
Comment 1 Rick Farina (Zero_Chaos) gentoo-dev 2018-08-02 14:00:00 UTC
Okay, so I just encountered an error where portage was pulling packages from the 2nd mirror in the list instead of the first.  It did it over and over again.  Please note there are 3 mirrors in my list right now, so I can't explain why portage picked not the first nor the last in the list, but the 2nd.

Clearly something is picking a mirror, no clue what.  Switching to have one in the list, the first one, everything worked, so I'm pretty sure it's not failing on the first and retrying on the second.
Comment 2 Brian Dolbec (RETIRED) gentoo-dev 2018-08-02 14:48:40 UTC
Zac, any idea why that would be?

if it takes them from the first when it is the only one, that would rule out the use flag differences...
Comment 3 Zac Medico gentoo-dev 2018-08-02 17:23:25 UTC
Maybe the fetch function is doing something wrong. The GENTOO_MIRRORS are added to the list here:

The list is reversed here, so that list.pop() is supposed to return GENTOO_MIRRORS from left to right:
Comment 4 Zac Medico gentoo-dev 2018-08-02 19:18:30 UTC
(In reply to Zac Medico from comment #3)
> Maybe the fetch function is doing something wrong. The GENTOO_MIRRORS are
> added to the list here:

Sorry I thought we were talking about GENTOO_MIRRORS rather than PORTAGE_BINHOST.

The PORTAGE_BINHOST code has no notion of mirrors, if multiple binhosts contain identical files then it always fetches from the binhost listed furthest to the left in PORTAGE_BINHOST, since the one on the right overrides the one on the left here:
Comment 5 Rick Farina (Zero_Chaos) gentoo-dev 2018-08-02 19:36:13 UTC

Considering the (what seems to me to be) confusing difference, can you please make PORTAGE_BINHOST work more like GENTOO_MIRRORS?

Trying things left to right instead of right to left would be a great start, and anything else you might thing a moron with 5 randomly rsyncing mirrors might need :-)

Also, I'm still looking for someone to actually implement support for PORTAGE_BINHOST in mirrorselect. :-D
Comment 6 Zac Medico gentoo-dev 2018-08-15 17:22:08 UTC
Currently the binarytree class associates each package with a single BASE_URI and PKGINDEX_URI. In order to support mirrors, each package needs to be associated with a list of mirrors.
Comment 7 Zac Medico gentoo-dev 2018-10-11 18:41:05 UTC
In order to express things like this, it would be helpful to have support for binary package repository configuration files. This will make it possible to
specify mirrors for a particular binary package repository.
Comment 8 Zac Medico gentoo-dev 2021-01-18 02:42:07 UTC
Can revisit this now that binrepos.conf support is available (bug 668334).

For bug 668302 we added binrepos.conf support to allow customization of FETCHCOMMAND.