Experiment Underway To Improve Gentoo's Binary Package Handling With Portage

[phoronix]

Phoronix: Experiment Underway To Improve Gentoo's Binary Package Handling With Portage

Gentoo developer Andreas Hüttel "Dilfridge" is experimenting with binary Gentoo package hosting and finding out what improvements to Portage are needed for making it more of a reality at a larger scale...

https://www.phoronix.com/scan.php?page=news_item&px=Gentoo-Portage-Bin-Packages-Exp

[Adarion]

Interesting. Of course it kind of jeopardizes the Gentoo approach, but still, in some cases of elderly CPUs / low power CPUs I am happy e.g. for LibreOffice or browser binaries, as it takes long to compile and chroot compiling on an Zen machine isn't always handy. Moreover, a few times it might be good in case of bug reporting to check an official build it it exposes the same error, before complaining and then noticing that it is due to a compiler messup.

[kylew77]

The ability to mix binary and source packages could prove useful and it is a feature that FreeBSD which inspired the ports collection in gentoo lacks. Have code that is executed frequently like the c library and kernel compiled for mach=native -O3 and code that is update frequently like browsers or ran seldomly distributed as a binary.

[binarybanana]

Originally Gentoo was meant as a distribution build system ("meta" distribution), somewhat like how Nix is often used today as a container build system. I don't know of anyone but Google using it that way at scale (Chrome OS). I kind of use it that way, but not for entire server farms or thousands of desktop machines at once or anything like that. Mostly a custom config for box or two here and there built on my big desktop (the "build/binpkg server"). Works nicely, especially for machines with little storage and RAM, like a 256MB RAM SBC. Slurps way less RAM than most alternatives.

[mechanyx]

There was a distribution called RR4/RR64 and then Sabayon that was Gentoo with the option to install binary packages via a package manager called Entropy. I ran it for awhile and really liked it until the Entropy dependency solver was seemingly broken and you'd try to install some simple utility and it would insist on installing/updating 300+ unrelated packages. I don't know what happened to the distro after I stopped using it. The founder got a job as an SRE at Google so maybe he just didn't have time anymore.

This seems very overdue as FreeBSD has worked this way for IDK decades?

[ms178]

While I use makepkg and the AUR on Arch a lot for optimizing my own packages, providing something more optimized in binary form is great start that saves a lot of time for non-performance sensitive packages (but unfortunately this initiative is not about that, at least not currently).

I'd argue that there is no source vs. binary dichotomy, it is about offering a optimized baseline and making it as easy in terms of dependancy handling and as safe as possible from a breakage point of view for people to customize their installation to their own liking. Try to maintain a custom-compiled install of KDE-git desktop on Arch to understand my point (and handle all the qt5 updates, new dependancies etc.).

[skeevy420]

While I use makepkg and the AUR on Arch a lot for optimizing my own packages, providing something more optimized in binary form is great start that saves a lot of time for non-performance sensitive packages (but unfortunately this initiative is not about that, at least not currently).

I'd argue that there is no source vs. binary dichotomy, it is about offering a optimized baseline and making it as easy in terms of dependancy handling and as safe as possible from a breakage point of view for people to customize their installation to their own liking. Try to maintain a custom-compiled install of KDE-git desktop on Arch to understand my point (and handle all the qt5 updates, new dependancies etc.).

Using KDE's kdesrc-build helps a lot with that. While it isn't the Arch Way, it'll build KDE separate from your OS using your installed libraries so you don't get sucked into using bleeding edge dependencies like when using git-based PKGBUILDs.

[chocolate]

Sabayon again?

[scottishduck]

I have mixed feelings about the binary packages available in gentoo.

I think in instances where the package takes an unreasonably long time to compile, or has a built-in update mechanism that wont function when the app is compiled (LibreOffice, Firefox, etc) it makes sense to have binaries available as an option, but gentoo already has for years (*-bin packages).

The introductions of the kernel binaries made sense too. Kernel config can be challenging for new users and (generally speaking) a finely tuned kernel config only has marginal benefits (not that it'll ever stop me). A binary kernel download is also a great option for a recovery system.

The biggest benefit and the unique function of gentoo is customisability. USE flags are incredibly powerful and binary packages are inherently incapable of supporting it. I'm all for the inclusion of select binaries but gentoo should always be a compile-first distro.

[skeevy420]

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.

Now that I've had time to read more into it: Nearly everything there is available as a Flat from Flathub or KDE directly. While I see a lot of benefits to this for a lot of use-cases, Flats would work just as well for the end-user that doesn't want to or have the resources to compile things like Firefox.

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).

...

CFLAGS are chosen such that the packages will be usable on all amd64 (i.e., x86-64) machines.

They're also being built by a build server and not using the official binaries provided by the upstream projects; not using binaries from Firefox.com. Adarion suggested it could be used to compare local builds with official builds, but they're not technically official builds so that won't be the case here. For reporting official bugs to the upstream project, using Flats is a better option over this since the bugs may or may not be Gentoo or compiler related.

I feel like I'm being a Debbie Downer and I'm not really trying to be because this is actually a really cool initiative and great if you don't want to deal with very large builds that may or may not even benefit from 1337 compiler flags or if you don't want to Yo Dawg your system with Flatpak.