Gentoo: A Modular Approach

Right, so there was a a bit of furor over my last post about overlays.

Let me point out two things:

  1. Gentoo is not moving in this direction, these are simply my thoughts.
  2. I just want to get people thinking and discussing (maybe someday some of this will become a series of action items for someone somwhere).

Now, there is a bit of misunderstanding here. The idea that I propose is exactly to remove Gentoo’s “distro” status and restore its “metadistro” status. That does mean that Gentoo becomes a platform for other people to create distros out of. I want to address some of the comments here.

First of all, yes, there would be overlays: mostly they would be unoffical. But a few of them who pass some sort of series of evaluation tests would be considered “official.” When an overlay becomes official, it would be listed in make.conf as something sync’able. By default, all official overlays could become sync’able, and the user would have to opt out of the ones that they don’t want. That’s a detail and it’s unimportant. The important thing is that the package manager (be it portage, paludis, or pkgcore or some other), should be able to handle official overlays transparently.

Additionally, the environment is ripe for tools builders to build tools that can query packages in the official tree, offical overlays and unofficial overlays.

There is a definite challenge in that there might be interdependencies between the overlays. This is an issue that can be resolved, I should think. In fact, a requirement for being an official overlay might be to work those interdependencies out.

Finally, nothing stops someone from coming along and creating their own “unoffical-to-gentoo-but-official-to-themselves” overlay and packaging their own distro. Gentoo’s security team would handle its own security bugs (and those in official overlays). Derivative distros would have to have their own security teams.

And even more finally, I want to reinforce the idea that overlays can be official (and therefore part of the SYNC string, potentially) and unoffical (two guys building an Xgl overlay, for example). So users wouldn’t have to run around trying to find them. In fact, overlays.gentoo.org could serve as a central registry of all possible overlays.

Flame again: Kulleen, out.

Edit: Linked to xgl-coffee and changed the link for pkgcore to the official site

10 thoughts on “Gentoo: A Modular Approach”

  1. >The idea that I propose is exactly to remove Gentoo’s “distro” status and restore its “metadistro” status.
    >That does mean that Gentoo becomes a platform for other people to create distros out of.

    I think the only overlay approach is horrible. You’d get the fragmentation and associated admin problems that have already been discussed. The fact that gentoo is a *usable* distro keeps people motivated to keep it working.

    IMO you’d be much better off:
    * ditching any package which has no upstream (probs that Alex Warner has talked about- just let him punt packages.)
    * having 3 branches (or whatever the word is) like debian- unstable, testing and production
    * putting out a proper binary distro- after all if it’s so easy to make a distro why not just have an official one?
    * use the `flag days’ as point releases, and don’t have a situation where releases are rushed out and break users’ data

    That way, you can still install any of the 1000’s of source packages, but concentrate on professional releases of the common and large packages.

    You’d then have a chance of getting to the enterprise market (and you wouldn’t put off new users either.)

    Oh, and give your userreps more power! After all, a distro is nothing without users, gentoo more so than any other. The userreps would make a great buffer between the `devs’ and the users if you just let them.

    [Sorry I make a distinction between ebuild devs and actual coders like ferringb, blubb or whoever]

    I love gentoo, but it really seems to be going off the rails ATM. One of the main things I’ve noticed from user comments is that there’s too much snobbery from the devs, many of whom don’t seem to do much beyond maintain ebuilds- important as that is, it hardly qualifies one as a programmer.

    My 2p worth. (Flame on 😉

  2. I like the idea of stripping Gentoo down to smaller core but I don’t really like the multiple overlays.

    I think it would be better to follow the Ubuntu breakdown. Have the core OS and the universe for everything else.

    Gentoo developers could work on/maintain the core and some kind of ‘Masters of the Universe’ group would do the same for the universe.

    To prevent the universe from getting out of hand, have some process to regularly remove things that have no upstream, maintainer(s), or updates.

  3. lorenb,

    Now we’re getting to implementation details — the Masters of the Universe group would simply have to keep the overlays in sync with each other: make sure that “offical” overlays are within spec, make sure that interdependencies are worked out in a sane manner, and generally be the glue to bring the various overlays into (and out of!) officialdom, etc. That frees the Masters to be strategic, and it allows more people to be involved in the process (by being a true meritocracy: if your overlay is higher quality, then it becomes official, even if it supplants and renders unofficial some other one).

  4. I was only pointing out how our ideas aren’t that much different, and that overlays aren’t necessarily a bad thing, if looked at in a certain way. As for sunrise being the universe, that’s a little dicey, because it would lead to the same sort of issue as portage itself. Small things are easier to manage than large things. So a collection of well managed small things would do better than one monolithic large thing.

  5. In theory I don’t have a big objection to having everything in overlays. I guess my big concern how it will work in practice.

    Where are the overlays to be hosted? I’m not aware of anyone providing free rsync services. That’s a potential barrier to entry.

    I can see a scenario where by there is some unofficial overlay I want to use, the quality of the ebuilds is good and what not but it’s hosted on home cable/dsl connection.

    I really I don’t want to have to connect to 10 different rsync servers all of wildly different bandwidth quality on a regular basis.

    I agree the maintaining of a large monolithic collection isn’t easy and has it’s drawbacks. It does provide a common platform though.

    I’ve been using Gentoo since v1.2 and I remember how fast it used to be to sync up the tree when it was smaller.

    I definitely see the benefits of smaller overylays. Again, I’m just concerned about how it would be implemented.

  6. > I was only pointing out how our ideas aren’t that much different, and that overlays aren’t necessarily
    > a bad thing, if looked at in a certain way.

    OK, it just sounded like you were taking his stance as a validation of `overlays for everything,’ by saying “now we’re into implementation details.”
    (NB: I appreciate all the work you guys do!)

  7. lorenb, I did address the syncing of disparate overlays issue but I did not do it clearly enough. So let me hash the detail a little bit here:

    overlays.gentoo.org would serve as the central point for all official overlays. It would behave similarly to planet.gentoo.org: it would aggregate all the disparate overlays into one place. So a user would just have to subscribe to the overlays on o.g.o. The only time a user would have to go searching around or put any non gentoo.org overlays would be for unofficial overlays — that is as it is now.

    A management tool like layman could even help set up the appropriate syncs.

  8. StevenL, excellent post! We could use some Gentoo-specific tools for managing lots of desktops based on Gentoo. Etc-update is a pain.

Comments are closed.