Actually E. Andersen managed to build a full debian in there (but withuclibc) 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 verydisappointed. In that case this is little more than supporting Linux onMac or Sun with the elimination of documentation.... Not very useful for me.That is where the emdebian info would be usefull for. Not only solvingcross-compilation problems, but also further reduce the footprint if possible. The default "throw away docs" procedure enables us to build smaller Debianpackages easily and quickly and is just there for more rapid software availability.IMHO for deeply embedded systems you can better turn to uclinux. (this dependsof course on what you mean with deeply embedded)
My definition of deeply embedded us a flash based system. ucLinux is appropriate for non-MMU systems, otherwise the standard Linux implementations are fine. This does bring up a good point about target Linux distriutions.
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.It was also the basic idea to do the compiling for uclibc by default. Which is possible as Andersen has proved.... But leave the flexability to use glibc orsomething else if you wish. If we would do the compiling in a uclibc environment like Andersens buildroot we would at the same time (withoutreworked packages) reduce size by removing crufty docs and using a smaller libc. After this we could refine the packages with the emdebian/rules insteadod debian/rules.So I hope you do not feel left out :-) This is a more thought out developmentof Stag.
I do not feel left out. Clarification is good!