Experimental binary package host
This is an experiment, and should not be used for secure or critical applications, but just for trying things out. The host only provides packages for the stable branch of the amd64 architecture.
The binhost packages have the USE flags set as in an unmodified 17.1/desktop/plasma/systemd profile (with the exception of
USE=bindist). The packages can be used on all amd64 profiles that differ from desktop/plasma/systemd only by USE flag settings. This includes 17.1, 17.1/desktop/*, 17.1/no-multilib, 17.1/systemd, but not anything containing selinux, hardened, developer, musl, or a different profile version such as 17.0.
Currently, the package set includes kde-plasma/plasma-meta, kde-apps/kde-apps-meta, app-office/libreoffice, media-gfx/gimp, media-gfx/inkscape, and of course all their dependencies. More may be added at a later date.
The CFLAGS values are quite generic, such that the packages will be usable on all amd64 (i.e. x86-64) machines.
This content comes from dilfridge's blog, please leave feedback in the comments section on that page.
To use the packages, configure the binhost repository with Portage. Create a /etc/portage/binrepos.conf with the following content:
[binhost] priority = 9999 sync-uri = https://gentoo.osuosl.org/experimental/amd64/binpkg/default/linux/17.1/x86-64/
It is possible to pick a different mirror according to preference.
Edit /etc/portage/make.conf, and add the following EMERGE_DEFAULT_OPTS (in addition to flags that might already be there):
The next update should now download the package index and use binary packages whenever the versions and USE flag settings match. Everything else is compiled as usual.
Limitations and caveats
Obviously, packages are not "optimized" for the system processor. They should work just fine, as long as the system is of the amd64 instruction set.
Right now, the server only carries packages for the USE flag settings in an unmodified 17.1/desktop/plasma/systemd profile. If using other settings, some packages will automatically be locally compiled (which is not really a problem, just the benefit of the binary download is lost). It is technically possible to provide binary packages for different USE flag settings at the same URL, and eventually it will be implemented if this experiment succeeds.
No cryptographic signing of the binary packages is in place yet. This is the main reason why this is still explicitly experimental. Effectively, users have to place trust in the mirror admins, and in the HTTPS protocol. Package signing and verification is in preparation, and before the binary package hosting "moves into production", it will be enforced.
Some issues may theoretically appear when using binary packages and when there are certain core system component updates - see bug #753500. The maintainers are aware of this however, and will try to avoid it leading to issues.
- Binary package guide — Next to the usual support for source-based ebuilds, Portage also supports building and installing binary packages.