so scary i almost glep’d it…

I had this thought on the way into work this morning, and it scared me so much I almost wrote a glep for it. (I got better. Or rather, I got to the office where in my absence things had to turned to crap and caught fire and required a laying on of the asbestos).

I have the opinion that the tree is too big. Or rather, the parts of it we download every sync. Now one approach to this ‘problem’ (that maybe I alone perceive?) is to weed out the old, unused, and redundant ebuilds. But even that slimming action wouldn’t do for much, right? So that idea sorta fell down and sank in the swamp.

Then I had a follow up thought that maybe we should have multiple overlays (I think seemant might have suggested this a few days ago, but pointing at it here would require me to break my train of thought all over again). You’d have a baselayout overlay, with a core team, then each project would (basically, in my rendition) have a series overlapping overlays that sat on top of that. You could then pick and choose what you wanted. But then you run into issues with maintaining multiple repos. ack.

So that idea burned down, fell over, then sank into the swamp.

So, wheels now turning (or churning I guess), what if instead of overlays, we just utilized rsync properly from within make.conf/portage itself? What if we simply maintained a series of categorized lists (like,”X”, “gnome”, “kde”,”window-managers-other”, “lamp”, “games”, etc.) which were really just rsync include/exclude lists? Bear with me while I attempt to flesh this idea out a wee bit more…

My notion is the default mechanism would be to assume they want it all. But rather than asking the users to do a piecemeal exclude list, we maintain an set of include lists to cover our categories. Over time, make.conf would be paired down to include just the baselayout, maybe a little something more. Maybe.

Why? It’s all about the size of the tree, really. First, there’s the speed of synch’ing itself. With a properly organized set of include lists, I’d wager most folks won’t be downloading everything, which saves on bandwidth if nothing else. The next advantage would be at the essential distribution level – with a smaller tree for users to work with initially, that means more tools can be crammed on to the cd’s.

I’d say more on this, but I’m starting to lose my steam, and I don’t want this to sound like a debian-esque advocacy of world/universe/multiverse repositories, but with a gentoo spin. But it is, sort of, and that’s nothing to be ashamed of either.

This idea is the one you will inherit, son…(nothing like a little bit of the ol’ holy grail tossed into to keep it interesting 😉