Split moonbases from sofar, if you want it.

Auke Kok auke at foo-projects.org
Wed Apr 25 07:11:25 CEST 2012


I've started an experiment to run with a split moonbase. Effectively, 
I've cut moonbase into several distinct parts:

- core - this is what you'd get in an ISO image
- xorg - the base Xorg stack and most useful and common tools, drivers
- xfce - the entire xfce4 stack
- efl  - the enlightenment desktop
- riffraff - uncategorized packages that I'm not yet deleting from any 
of these trees
- deleted - I omitted about 2000 packages or so that moonbase has that I 
currently do not care about.

I'm not doing this for everyone, just for myself. However, I'm not 
keeping anything away from anyone else. I posted my git trees with all 
these packages here:

http://foo-projects.org/git/

Using these package list is fairly easy. Create an emtpy folder, lunar 
set MOONBASE `/path/to/that/folder` and then git clone the repo's that 
you need in there. You could even use git externals to pull them all at 
once if you wish to update against them.

Make sure you grab a copy of "aliases" too.

I'll take pull requests - send me an e-mail with a git pull request 
telling me what the changes are and where I can pull them from, and I'll 
be happy to merge other people's changes.

What's my motivation?

First, really basic, fix up the core package group so we can actually 
create ISO's with *just* the core packages. If that works, and we can 
build images automated from just that package group, things will be a 
lot simpler to make the xfce4 and efl package groups work without 
introducing too many complex dependencies. The key is that I want to be 
able to create "clean" installations for each desktop.

I won't do a KDE version, nor a gnome2 or gnome3 version, someone else 
could do this and build on the core+xorg package groups.

Where does this go?

I don't know. But I really prefer to have /core/ in my own control, so I 
can work on things like unifying /lib/ <-> /usr/lib/, work on a 
systemd-based ISO, etc.

I'm also very tired of having 3500 potential problems inserted into the 
dependency chain of the few packages I really use, so, removing them or 
giving me the ability to eliminate them from the equation is a big 
improvement.

Auke


More information about the Lunar mailing list