Binary Gentoo project (tried)

dE_logics · Advocate Joined: 02 Jan 2009 Posts: 2253 Location: $TERM

Looks pretty -

NeddySeagoon · Posted: Mon Sep 13, 2010 8:29 pm Post subject:

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 · Posted: Tue Sep 14, 2010 8:24 am Post subject:

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

Kollin · Posted: Tue Sep 14, 2010 9:03 am Post subject:

AllenJB · Veteran Joined: 02 Sep 2005 Posts: 1285

(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 · Advocate Joined: 02 Jan 2009 Posts: 2253 Location: $TERM

krinn · Watchman Joined: 02 May 2003 Posts: 7470

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 · Posted: Tue Sep 14, 2010 3:50 pm Post subject:

AllenJB · Veteran Joined: 02 Sep 2005 Posts: 1285

dE_logics · Advocate Joined: 02 Jan 2009 Posts: 2253 Location: $TERM

Shining Arcanine · Veteran Joined: 24 Sep 2009 Posts: 1110

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 · Advocate Joined: 02 Jan 2009 Posts: 2253 Location: $TERM

Shining Arcanine · Veteran Joined: 24 Sep 2009 Posts: 1110

dE_logics · Advocate Joined: 02 Jan 2009 Posts: 2253 Location: $TERM

Shining Arcanine · Veteran Joined: 24 Sep 2009 Posts: 1110

cach0rr0 · Posted: Mon Sep 27, 2010 9:19 pm Post subject:

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