Full support for binary packages would be very handy and would attract all those
users who don't have time to compile everything from source, but also want an
easy way to update packages.
You could add it using a PACKAGE_TYPE variable in make.conf, containing the
priority order of the packages you want to install:
i.e. a lazy user with an athlon-xp will have something like this:
PACKAGE_TYPE="athlon-xp i686 i386 source"
This means "download and install packages optimized for -march=athlon xp; if not
available, use packages compiled for -mcpu=i686, then i386. If none of these are
available, compile from sources using CFLAGS".
An advanced tweaker (also using an athlon-xp) would instead have:
PACKAGE_TYPE="athlon-xp source i686 i386"
that means that i686 and i386 packages should only be used for closed-source
Any user could obviously want to override this option for particular packages, i.e.
#PACKAGE_TYPE="source" emerge mplayer
For this to work, you'd have to write in the ebuild files links to several
packages, that is the source and some .tgz, i.e. (for mozilla)
emerge would download the correct package according to PACKAGE_TYPE, then run
emerge -k on that. The -k option would not be needed by the user any more.
Obviously you don't need to make binaries for *all* packages, just the main ones...
I was just going to post sometihng like this too. I would also like to see some more support for binary packages. I believe it would definitely bring more people to gentoo too. maybe just keep them as <package>-bin like a few still are right now?
I believe this could be possible using ferringb's domain stuff and multiple
binary repos + emerge -k --MyAthlonXP Repo or some kind of repo order similar to
Regardless, it's not going in stable, so LATER.
Yeah, comes down to repo type, and shopping the built pkg around to the mergable
repos (rpm, binpkg, dpkg, whatever).
I'll stick to binpkg repo myself in writing it, but if anyone is whacky and
wants to play with some rather in-flux code, contact me if you're after
Closing as WONTFIX, this would be covered by generic multi repository support as outlined in comments #2 and #3