Hi Erik,
Fedora has a set of tools now called Appliance-Tools [1] for creating this sort of thing. You can use it to specify a minimal build and then pull in the extra stuff you want, specify repositories etc. I used it to build a joyride VM I could use for slicing and dicing package deps and the like the other day in around 15 mins (plus the time it takes to construct the actual filesystem etc). I can post the kickstart file somewhere if your interested in using it as a base. The image it produced has a boot issue that I need to get time to fix (or work out why its got root fs issues) but it was a quick demo to see if it helped.
I heard about these (appliance tools) from Reuben. Any documentation you can post would be highly useful. There are a lot of ways to achieve a similar result, and a lot of people appear to have duplicated effort as a result. I think this is good, as it gives us some degree of selection moving forward. Eventually we need to coalesce effort around one system if we are going to update OLPC's build infrastructure successfully.
The kick start file can be found on my fedora space [1] and the commands I used were essentially appliance-creator --name OLPC-4 --config olpc-4.ks and if you use virtmanage the following command to import it. virt-image OLPC-4/OLPC-4.xml
All these sort of tools are what's used to create fedora. Things like mock and koji from the build system side of things and livecd-tools and appliance-tools and the like to build the livecds etc. So from a development point of view they're probably the direction to be headed. jkatz who is around on fedora-devel (and devel@laptop too I think) would be the one to shed more light in this direction.
FWIW: The boot issue might be related to nash's mount command not working for jffs2. The quick and dirty way to get around it was to drop busybox into an initramfs and change the root partition mount line in the init script to use busybox's mount command instead of nash's. Found nash extremely unweildy and am curious why it is used in the initramfs. The initrd I produced is: http://dev.laptop.org/~erik/rpmxo/initrd.img-2.6.25-20080925.1.olpc.f10b6543... (It is built against the stock 8.2-767 kernel using stock Fedora initramfs-tools, I just unpacked it and dropped busybox and its library deps in and made the afformentioned hack to init.)
I specified a ext3 fs so it would be easier to deal with on my laptop so it might not be so easy :( but I think it might be the device I used or something.
I think this is what you are after. There are still some issues with packages pulling in too many deps and as time permits I'm trying to work through most of these issues while not having to fork half the distribution which in turn makes it more work for the OLPC guys. Its a fine line.
Yes. This seems to be endemic, but it appears to be generally a problem for systems which don't get stretched in this direction (I have seen the same kind of bloat while testing Ubuntu builds).
Its one that quite a few in Fedora are well aware of and people are slowly moving towards. There are a number of SIGs (special interest groups) that are looking to reduce them from different directions. I also hope the push from GNOME to get rid of libgnome/bonobo/gnomevfs etc should settle down and reduce a lot of them before long too. eg most gnome 2.24 now don't depend on gnomevfs but some of the bigger apps like firefox always trail.
I can help you as much as possible, I'm relatively free for the next couple of days but will be then travelling over the next couple of weeks so will have limited connectivity.
Great! Any way you'd like to help. Paring down dependencies is crucial. 'Minimal' package lists would be also very helpful. I am hacking mine together and I'm worried I might miss critical things that would be obvious to a more experienced Fedora developer.
Critical packages? They should be auto pulled in by yum. Or do you mean by paring down dependencies in actual packages. If the later let me know what the packages are so I can review changes and see if we can't just get them upstream (in a lot of cases we can split some of the deps out to sub packages in other cases they might be superfluous). Or maybe I've missed the point too :)
One package-level curiosity I've had is how to auto-remove packages which were automatically installed to satisfy the dependencies of a manually installed package after said packge is removed.
Well in the case of appliance tools that create images on the fly it just won't pull them in. For already installed systems I'm not sure there is for auto remove but there are some tools that identify unused deps. I have a note of some of them somewhere, I'll try and dig details out.
Cheers, Peter
-
Peter Robinson