Gentoo's big attraction for me is Portage. It goes beyond just providing a build environment and dependency management. Ebuilds (Gentoo packages) are supported by great tooling and Eclasses that handle a lot of corner cases in builds. Developing Ebuilds feel like doing a real software project, and is great for anyone who wants to experiment with packages that are not in the official repository. Coincidentally, I just published a tool to manage unprivileged chroots for testing ebuilds.
This development will make Gentoo more accessible for a lot of people. But I guess this isn't for me. My build configuration (like CFLAGS) are never going to match the official binaries and so they will never get used.
I agree on customizing the package flags, and features. When using Gentoo in production it became an important part of our security posture to omit the features and integrations with unused software.
That being said we've always had a build host dedicated to producing binaries, but the actual support for binaries in Gentoo hasn't been great. Unsigned serving over HTTP or NFS of compiled artifacts is about all you get. I'm really pumped to see that the new package format adds in cryptographic verification that really should have been there all along even for internal only serving.
> There are so many plugins, connectors, protocols, and often the old neglected ones turn into attack vectors.
Practically speaking this is probably true but theoretically a distribution's job should be to somehow guarantee that a specific package built their way gets the security fixes for the way they built it.
This is anyway tangential to the fact that in security "less is more".
For me this is great news for less powerful devices I use that I don't feel like setting up a binrepo for (especially when it involves cross-compilation), but still want to reuse my portage config and custom ebuilds for.
For less powerful devices it has always been possible to install Gentoo in a chroot directory on a powerful computer, using a configuration appropriate for the less powerful device, compile and install in the chroot environment any packages, and then just copy all the files from the chroot directory, through Ethernet or using a USB memory, over the root HDD/SSD of the less powerful device.
I have used Gentoo in this way on many small computers with various kinds of Atom CPUs and with a small DRAM memory and small and slow SSD/HDD.
With multiple computers of a compatible kind, the files from such a chrooted installation compiled on a powerful computer can be copied over all of them and everything will work fine. If the chrooted installation is preserved, it can be updated later with other software packages and all the changes can be propagated with rsync on all other computers.
Linux is not like Windows, which will complain when run on a different computer than that on which it was installed initially.
I know this, I mentioned this as "setting up a binrepo" in my comment, as I think the binrepo approach makes more sense (esp. with regards to easy updates).
It's just an unwieldy amount of extra overhead, disk space, and time, which I'd rather avoid, especially for devices I'm not fully committed to maintaining over a long period. I've tried what you mention, it's just never convenient enough to be worth the pain.
I am not sure what you mean, but in the chrooted environment where you compile for a distinct machine you obviously use configuration options, including compiler flags, appropriate for the target computer, not for the host computer, so "-mtune=native" cannot be used.
My point is that you do not need to setup a binrepo or any other complication like this.
You can install easily Gentoo on a very weak computer, by performing the installation on a typical desktop computer, which may run a different Linux distribution, not necessarily also Gentoo, and then just copying the files.
The Gentoo manual has always included information on how to install Gentoo inside a chrooted environment.
Although, I do somewhat think that working out good optimization flags for cross-platform compiles is a moderately unusual skill, even among people who compile things regularly. Hopefully I caveated that sufficiently, I’m not saying it is a hyper-advanced dark art or anything.
I have in the past set up code on a cluster to just compile on one node for the first run with -mtune=native because I’m lazy!
This tool [1] does the exact same thing - except that you nuke the chroot when you're done. And the reason is the same - to find all necessary dependencies. I had a small script that eventually became a Rust program. Then I kept adding features to it until it became what it is now. That's the reason why I never really got to explore the alternatives. Anyways, it's usable and nearly done.
Thanks for suggestion though. I'll take a look at it.
Yeah, my CFLAGS won’t either. But I have to say I’m tempted to script something up so I can override all the plasma-related packages to use the common ones, or something similar, so I build everything where I care about speed myself and let the gui stuff be binary packages. Would save a whole lot of build time, and I’m not sure it would be much of a loss.
Here you go [1], [2]. It's not completely ready yet - but it's usable. It should be OK if you plan to just modify or reuse parts of it. It currently supports btrfs backend. Plain directory backend and packaging of the tool are not done yet - but shouldn't be too hard. I was keeping it for tomorrow. Meanwhile, you can use asciidoctor to convert the docs if you need to refer it.
This development will make Gentoo more accessible for a lot of people. But I guess this isn't for me. My build configuration (like CFLAGS) are never going to match the official binaries and so they will never get used.