So what do we have, and how can you use it?
- The server builds an assortment of stable amd64 packages, with the use-flags as present in an unmodified 17.1/desktop/plasma/systemd profile (the only necessary change is 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 selinx, hardened, developer, musl, or a different profile version such as 17.0.
- Right now, 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 will possibly be added.
- CFLAGS are chosen such that the packages will be usable on all amd64 (i.e., x86-64) machines.
To use the packages, I recommend the following steps: First, create a file /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/
You can pick a different mirror according to your preferences (but also see the remarks below). Then, edit /etc/portage/make.conf, and add the following EMERGE_DEFAULT_OPTS (in addition to flags that you might already have there):
EMERGE_DEFAULT_OPTS="--binpkg-respect-use=y --getbinpkg=y"
And that's it. Your next update should download the package index and use binary packages whenever the versions and use-flag settings match. Everything else is compiled as usual.
What is still missing, and what are the limitations and caveats?
- Obviously, the packages are not optimized for your processor.
- Right now, the server only carries packages for the use-flag settings in an unmodified 17.1/desktop/plasma/systemd profile. If you use other settings, you will end up compiling part of your packages (which is not really a probem, you just lose the benefit of the binary download). 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.
- At the moment, no cryptographic signing of the binary packages is in place yet. This is the main reason why I'm talking about an experiment. Effectively you trust our mirror admins and the https protocol. Package signing and verification is in preparation, and before the binary package hosting "moves into production", it will be enforced.
Nice! Right way!
ReplyDeleteIt's not all that hard. I've been doing it for all the Gentoo servers I've had to admin for years. You'll get there.
ReplyDeleteSure, I've been doing it too for a while. And it worked very well for a group of machines with same profile and similar configuration. The point is to find out 1) if people are interested (yes definitely), 2) what's missing in Portage and in the remaining tooling, and 3) what's missing for larger scale "official" deployment.
DeleteHi Andreas,
ReplyDeletegood idea!
Perhaps you could easily circumvent some limitations by borrowing from MKG code (https://github.com/fabnicol/mkg) or the corresponding wiki (https://github.com/fabnicol/mkg/wiki).
MKG is a GitHub-hosted project that offers regular build in the Realeases section, and a command-line tool to automatically create those builds from customized source packages built by GitHub Actions workflows. You can optionally dockerize the whole building process too.
Both projects have overlapping objectives even though some concepts differ. MKG removes some of your limitations (at least partially):
- you can optimize your builds using cflags
- several profiles are proposed (plasma and desktop, openrc and systemd, hardened is still experimental yet seems to be working)
- GitHub workflows provide third-party checksum verification of the source packages from which your local computer will automatically build the images.
However, owing to GitHub limitations, binary building cannot be performed using Actions workflows, so the binary in the released section are manually uploaded on a regular bases and verified by checksums.
Thanks! That looks interesting, I'll have a look. Then again, for the moment I want to wait a bit for some preparations to fall into place and then ask around. We already have several Gentoo devs who run tinderboxes and/or build CI systems, and have experience with building large package sets - so just the right background and existing code bases.
DeleteHello Andreas,
ReplyDeleteIs is possible to define a "whitelist" for which packages are pulled as a binary?
What I have tried is:
Create /etc/portage/env/binpkg.conf, which contains:
FEATURES="getbinpkg"
And then, in /etc/portage/package.env:
net-libs/webkit-gtk binpkg.conf
Which unfortunately doesn't seem to work, while invoking FEATURES="getbinpkg" emerge ... does.
I don't know if this is a know limitation to portage, or something undiscovered.
Cheers
Sounds like a nice feature request for portage.
DeleteThe problem with binhost is that portage lets you shoot yourself in the foot. When binhost updates glibc all new packages will be built against that new glibc. If a client now updates those packages + glibc portage doesn't force him to update glibc first. So portage will happily emerge wget linked against a new glibc before that glibc version, leaving you with a dysfunctional wget. Imagine that happening with coreutils or util-linux.
ReplyDeleteUsers must be really careful and manually intervene when toolchain or glibc updates are mixed with other packages or they may end up with a broken system.
This is on Bugzilla as https://bugs.gentoo.org/753500.
DeleteI think as a stopgap, we could rebuild all binpkgs on any official binpkg hosts when glibc and such gets upgraded.
Known problem indeed, Sam already cited the bug. For the moment and for glibc, a workaround is to provide a "new glibc" binary package early (so people upgrade), but delay upgrading of the build server itself (so packages only require the old version for a transition period). Of course that requires manual handling though.
DeleteIt was a while ago now, but I recall making the packages generated by Catalyst available for MIPS platforms available for download so people could update existing installs (core packages).
ReplyDeleteI don't recall much feedback of either variety.
Yep, generally publishing the stage3 packages would be an option too. For the moment, let's just test with amd64 though.
Delete