On 4/18/25 4:23 AM, Stefano Crocco wrote: > Hello to everyone, > I'm thinking of switching my old laptop to using the binary host, since > compilation times are becoming a bit too long for my tastes. > > I started looking at the documentation for the binary host quickstart [1] and > everything seemed reasonably simple. However, I noticed that in the "Package > settings" section for amd64 it states: > "This binhost is built with USE flags of the following profiles: > > default/linux/amd64/23.0/no-multilib > default/linux/amd64/23.0/desktop/gnome > default/linux/amd64/23.0/desktop/gnome/systemd > default/linux/amd64/23.0/desktop/plasma/systemd" > > Since my current profile is > default/linux/amd64/23.0/split-usr/desktop/plasma, > am I right that I won't be able to use the binary host? If needed, I think I > can switch to the non split-usr profiles, but I'd rather not switch to the > systemd one. Has anyone tried using the binary host with a non-systemd plasma > profile? If so, how did it go?
Binhost maintainer here. This should work fine. We don't build every profile because it would be fairly excessive and we only have a certain amount of compute to go around. Each listed profile is more or less "guaranteed" to have package availability covering the entire base system as well as the popular apps we install for those profiles. But *all* profiles under the general umbrella of linux amd64 with glibc should be binary-compatible with each other. The different sub-profiles just change which USE flags to build with, so if you are using openrc + split-usr + plasma then any packages which have USE="systemd -split-usr" will simply be rejected by `emerge` and you will have to build those yourself in the end. You may not be able to get as many binary packages as you would on other profiles, but you should still be able to get quite a bit of use out of it. Do note, that any packages which have USE="split-usr -systemd" (your openrc-based system) may still be built by two of the binhost profiles, and as long as they don't also have USE flags enabled by default on the KDE profile but not enabled on the gnome profile, you'll still get a good enough match. The number of packages that have KDE-specific USE flags and *also* compile against systemd is much lower than the number of packages that have only one of those two conditions. So you should still be able to benefit for most packages. You may want to run "equery hasuse split-usr" and decide whether you really need any of those packages to have binhost availability. The binhost does not build any USE=split-usr packages, but very few packages actually need that much knowledge of the split-usr profile (mostly the profile simply allows testing in profile.bashrc, and force masks systemd packages). On my system: $ equery hasuse split-usr * Searching for USE flag split-usr ... [IP-] [ ] app-alternatives/awk-4:0 [IP-] [ ] app-alternatives/bzip2-1:0 [IP-] [ ] app-alternatives/cpio-0:0 [IP-] [ ] app-alternatives/gzip-1:0 [IP-] [ ] app-alternatives/tar-0:0 [IP-] [ ] dev-libs/lzo-2.10:2 [IP-] [ ] net-mail/mailutils-3.18:0 [IP-] [ ] sys-apps/baselayout-2.17:0 [IP-] [ ] sys-apps/coreutils-9.5:0 [IP-] [ ] sys-apps/shadow-4.14.8:0/4 [IP-] [ ] sys-apps/systemd-256.10:0/2 [IP-] [ ] sys-libs/ncurses-6.5_p20250125:0/6 All those packages you will definitely still need to build yourself. Except for systemd, which you obviously will not be building or installing regardless. ;) -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
