Binary Gentoo project (tried)

[dE_logics]

Looks pretty -

[NeddySeagoon]

dE_logics,

I think some of your discussion is fatally flawed. Basically, Gentoo is not a distro at all. Its a set of tools that allows users to build their own distro.
As a result, no two Gentoo installs are the same.

Given that Gentoo is a toolkit, not a distro, the concept of binary-gentoo falls apart, as you would in effect, use the Gentoo toolkit to make a binary distro, that is not at all binary-Gentoo, as its what you (or binary-Gentoos devs) will decide to make it. Whatever that is, it won't be Gentoo.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[tomk]

Moved from Portage & Programming to Gentoo Chat as it's not a support request.
_________________
Search | Read | Answer | Report | Strip

[Kollin]

[AllenJB]

(This post is written by someone who considers Gentoo to be a "distro", just a different kind of distro from every other distro he's ever encountered. While there may be things that make Gentoo a meta-distro, explaining this to everyone is just too time consuming, so IMO Gentoo is a "distro" because it just makes life easier to call it a distro).

[dE_logics]

[krinn]

I don't think it's a viable project, it would be ok if you handle all cases gentoo can met, and provide package for those case, but it's impossible.

for every package you will need tons of binaries :
(let's say we are kind and pickup one example for x86 users with gcc-3.4.4 and glibc-2.11.0 that wish emerge the package name "fruit" that have (only) two use flag (named: "one" and "two")

this, just for that package, gives you those binaries:
fruit-x86-gcc3.4.4-glibc2.11.0
fruit-x86-gcc3.4.4-glibc2.11.0-one
fruit-x86-gcc3.4.4-glibc2.11.0-two
fruit-x86-gcc3.4.4-glibc2.11.0-one-two

This way you cover all cases a gentoo user might met for that "fruit" package.
But without even taking another arch, the gcc version, glibc version might expand that list to an amazing 50 binaries: just for one package !

[Mousee]

[AllenJB]

[dE_logics]

[Shining Arcanine]

I think that this is more feasible than other people think, although it would be to Gentoo what Ubuntu is to Debian. You would need to compile generic kernels, bloat packages with as many USE flags as makes sense, setup an overlay to host the kernels, make another overlay to host userland components and then implement some sort of forced reinstallation every time a core library changes and the changes require things to be rebuilt according to revdep-rebuild.

You would also need to implement a GUI installer and a wrapper for the system package manager. The forced reinstallation on binary compilation breakage is not going to be done by portage, because there is no facility in place to detect these changes when updates are done. While it is possible to implement such an infrastructure in Gentoo Linux, installing the binaries will make portage either think that the issue was resolved or make portage enter an infinite loop, neither situation being acceptable. This is because whether or not the binary packages are up to date is not an issue about which portage would care and any sort of out of sync issue would cause either of those scenarios depending on how the mechanism is designed.

To avoid having changes to portage break the wrapper, some changes to portage would likely be necessary to subjugate portage to the task of functioning as a back-end. With the blessing of portage's developer, portage could be split into a back-end part and a front-end part. The front-end part would be a traditional Gentoo front-end and would interact with the back-end through an extensible portage-specific API. Portage could be given a USE flag to state whether or not it is to install its front-end. The traditional front-end then could just be one of several front-ends, such as GUI and commandline front-ends that function as wrappers which implement the checks needed to ensure that binary compatibility issues are handled properly.

Such a distribution would likely need to support user compilation of kernels, so having two ovelays (kernel and userland) be separate from the kernel overlay would be necessary so that people could choose to manage their kernels themselves. Whether or not users are using their own kernels or the overlay-provided kernels would need to be considered by the wrapper for the package manager, so that it avoids reinstalling binaries for packages are recompiled by module-rebuild rebuild, which might occasionally cause problems for users that compile their own kernels, but that seems unavoidable to me. Most of them could likely be avoided by warning them about kernel updates and allowing them to do them separately. The wrapper for portage would likely handle the details.

A challenge that would need to be considered is how to configure the boot loader in a way flexible enough for the parent distribution's methodology to be used in the case of a custom kernel, but inflexible enough that kernel upgrades could be performed without breaking the system when the provided kernel is used. The wrapper would also need to be in its own bin-sys-tools overlay, an overlay for all of the userland components that make having the binary version possible.

Lastly, Gentoo's extensive architecture support and alts projects would need to be unsupported in the derivative distribution in the name of keeping the scale to something manageable.

I think that if these considerations are made it is quite feasible to derive a binary rolling distribution from Gentoo. The creation of such a distribution could cause the merger of the Arch Linux and Gentoo Linux communities. Another possibility would be getting other rolling distributions (i.e. Debian-derived rolling distributions like Linux Mint Debian Edition) to adopt the derivative distribution as their platform and extend it to get their own distributions out of it.

[dE_logics]

[Shining Arcanine]

[dE_logics]

[Shining Arcanine]

[cach0rr0]

my two cents:

I'd have more interest in community-driven public binhosts. Maybe even something done through the overlays.

And to that end, a bit of doc on the wiki that explains how to use said binhosts.

I think KDE4 users especially would enjoy the time saved

It would still need to be a full time project keeping the binhosts maintained, but I think you'll gain more ground that direction than trying to formally fold anything into gentoo, or creating an entirely new 'distro'
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash

[dE_logics]

So finally, this became a reality.
_________________
My blog

[eschwartz]

Yup.

And lots of interesting discussion from 14 years ago. Mainly interesting because it appears to have been pessimistic in unusual ways about how this could or would work -- in particular, the fact that portage already has a way to handle all sorts of rebuild scenarios e.g. dependencies can have SLOT bindings as well as configured USE flags, and portage will simply not consider a binhost package as a candidate if it was built for a different libpng SLOT. It transparently falls back to compiling from source.

Also, the binhost can have multiple copies of the same package compiled for different USE flags.

Of course, this took quite some time to get all polished. e.g. having multiple copies of the same package uses FEATURES=binpkg-multi-instance, which was added in 2015! Or migration from xpak to gpkg, which was added in 2022 and needed for security signatures. And that's really, probably, the reason why 2010 and 2024 look so different in terms of perspective on using binhosts. It took a long time for portage to enable all the features necessary to roll this out at scale, features which also allow people to run their own personal binhosts or even just save binaries of their own packages for quick cp'ing across local machines with greater peace of mind that those packages will do the right thing.

As a quick note: the current design means it's very easy to maintain the binhost, we just have a server with a few chrooted gentoo installs and they just emerge a lot of packages with different `eselect profile` options and a common /var/cache/binpkgs which is then uploaded to the mirrors. Most of the actual maintenance I actually end up doing on the binhost turns out to be solving package.use issues after stuff like the KDE 6 upgrade.

[C5ace]

"Calculate Linux" www.calculate-linux.org
is a Gentoo Binary Distro that uses 'cl-update ....' for binary packages and 'emerge ....' for source packages.
I use Calculate Linux on one of my families laptops.
_________________
Observation after 30 years working with computers:
All software has known and unknown bugs and vulnerabilities. Especially software written in complex, unstable and object oriented languages such as perl, python, C++, C#, Rust and the likes.

[flysideways]

I'd rather see the documentation for local binary hosting and catalyst being written to the level that even luddites like me can find their way through with minimal other outside help.

Gentoo has been the toolset to create stuff my way, and I've gotten to keep the the parts that I have broken.

Recently I have been in the arm64 space with both Apple Silicon and Pi's. I will tell you, that when there are tools in Debian arm64, that I am bugging because they are not even keyworded in Gentoo, we are at an inversion of the Linux space from not too many years ago.

Even though I have strayed at times when I needed a tool and did not have the time to maintain it, I always came back.

It will be doom, if too many of the Gentoo developers think they are working on the next best distro, and not the premier toolset for creating your own distro.

[eschwartz]

[dE_logics]