The way Portage currently handles binary packages is designed to accomodate homegrown repositories, ie. a store of custom-built binaries within a single organization. It is not, however, built to support a primarily binary-based installation, say a user on a slow machine that only installs GRP binaries. I propose to bring binary package support up to the level of building-from-source, to better accomodate a binary-based Portage system (GRP or otherwise). MULTIPLE BINARY DOWNLOAD MIRRORS /etc/make.conf currently allows one to specify multiple mirrors from which to download source files. However, it only allows for *one* binary download mirror. There seems to be no good reason why not to allow multiple mirrors. The ability to use mirrorselect to choose multiple mirrors would be great as well. MULTIPLE LOCAL SOURCES Portage currently only searches /usr/portage/packages/All for binaries on the local system. However, GRP binaries are distributed on CD-ROM, so in order to make use of them, the user must first copy the binaries from the CD to this directory. Would it not make more sense to allow Portage to search the CD-ROM directly? I propose the ability to specify in make.conf multiple local directories to search for binaries, which would include /mnt/cdrom. I suppose binary support has been somewhat lacking in Portage as nobody seems to really use it. I don't know of any binary mirrors that actually exist on the internet. However, perhaps "if you build it, they will come." Reproducible: Always Steps to Reproduce: 1. 2. 3.
Multiple binary mirrors only works if they are perfect copies of eachother. In any other case you are using mis-matched sets of packages and there is not perfect way to ensure that they work well together. Use a dns RR or stick to one mirror. As for local mirrors... It is perfecly acceptable to put a filesystem path in your mirror variable. Space seperated list.