Re: BuildRoot like tool

[Allen Curtis <acurtis@onz.com>]

> > > What is the vision for the root file-system build? I assume that
> > > everyone is familiar with uclibc's BuildRoot. Should we make 
> > > something
> > > like that? Does it fit into the Debian mold?
> >
> > 1. I think that such a cross compilation script would be interesting. 
> > We
> > are using something like that for our firmware.
>
> The idea is to use a modified Debian build system. I made a proof of 
> concept
> about it last year. It works nicely with dpkg-cross. I am working on a 
> new
> version as we speak, because the last one was outdated by the changes 
> in
> debhelper, dpkg, and dpkg-cross. I have to modify one more file 
> tonight and I
> can start debugging. It should do native builds, but throw out docs, 
> man,
> examples of debian packages automatically, or cross-compile using 
> dpkg-cross.
> Eventually using a new meta-data dir (emdebian instead of debian) to 
> solve
> cross-compilation problems.

I believe there are 2 parts to this problem.
1. Create the initial root file-system which is "bootable" by the target
2. Build additional applications to add to the initial root file-system.

The reason for the separation is the difficulty of cross compiling some 
packages. It may be possible that we need to punt and compile some 
packages on the target. (or in an emulated environment)

> > 2. The question if it fits within the Debian mold follows an answer to
> > the definition of embedded and to which systems GNU/Debian fits. IMHO,
> > buildroot is intended for more 'deeply embedded' systems: 
> > busybox/uclibc
> > covers most of the basics; ensuring a very small root filesystem (< 1 
> > MB).
>
> Actually E. Andersen managed to build a full debian in there (but with 
> uclibc)
> but only natively. If we can do the same with the modified tools we 
> could
> maybe do this natively and cross-compiled.

If this project intends to ignore "deeply" embedded systems, I am very 
disappointed. In that case this is little more than supporting Linux on 
Mac or Sun with the elimination of documentation....  Not very useful 
for me.

> > I think GNU/EmDebian is rather intended for slightly higher level
> > systems, where the choice is made to remove 'crud' from a normal 
> > system.
>
> I guess you will  not mind if we try using uclibc instead of glibc for 
> that also.
I was happy to see that uclibc was used in Stag for ARM processors. I 
personally believe that we should standardize on uclibc, or something 
similar, with the goal of achieving the smallest footprint possible.

-- Allen