Slimmed Down Fedora 10 on XO (was Fedora 10 on XO)

[Erik Garrison]

On Wed, Dec 17, 2008 at 12:32:58AM +0100, Peter Robinson wrote:
> >> The hard part will come when we need to pick the bare minimum set of
> >> functionality. I especially want to know what additional
> >> libraries/RPMs/features we need to install beyond what we alrady have in
> >>   XO 8.2.0.
> >
> > I have been quite frustrated with the Fedora toolset in this regard.
> > Getting a bare minimum of functionality is not something which these
> > tools are typically used to do.  The experience of building a Fedora
> > system from 'scratch' contrasts starkly with what we find in Debian,
> > where debootstrapping is a common development pattern which is
> > well-supported by the community.
> >
> > It can be done, and I am going to seek as much help from the Fedora
> > community in doing so as possible.  It just isn't easy and I have felt
> > like there are a lot of problems in using Fedora in this fashion which
> > will have to be resolved to make it easy for deployments to use such a
> > build script.
> >
> > (I sincerely hope someone flames me here as any attention to this issue
> > is good attention.)
> 
> 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.

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.f10b654367d7065.busybox
(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 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).

> 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.

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.

> I have no issue with the flames, but would much prefer to help you out
> than flame back :-D

And I prefer to cooperate as well!

Thanks,
Erik