+++ Philippe De Swert [04-01-12 01:28 +0100]: > Hello All, > > > Actually just compiling Debian packages with uclibc IMHO is not very hard. > ...with the help of dpkg-cross ... > However you did not get rid of the extra documentation etc...
Agreed. > Nor is there any hint that the package has been build with uclibc... making > it > very hard to differentiate between normal and emdebian packages. I would > suggest > a naming cheme then which makes a difference like application-(g or > u)clibc-embed... Hmm, you have a point. I was imagining that our packages would have exactly the same names as the normal Debian ones, but if we want to be able to mix Emdebian and Debian packages then that won't work. Is is possible to run emdebian (uclibc) and Debian (glibc) packages on the same system? Is ought to be, but is that a sensible goal? It might be convenient for testing/development but if you are going to have to install glibc anyway then why bother using uclibc in the first place. If we aren't going to mix Debian and emdebian then having different names isn't stricly necessary, but might still be helpful. There already _is_ an emdebian naming scheme, described at the top of the gcc page: http://www.emdebian.org/distrib/gcc.html (we add an 'e1' 'e2' etc suffix to the normal package name). We might as well stick with that unless anyone can thingk of a good reason why not. > Also you could limit the choice of the libraries by using this approach. I'm not sure what you mean here? Which approach, and why would it limit library choice? > Another problem is the installation. You need a running file-system or a sort > of > chrooted environment with a working dpkg or something similar (thinking about > ipkg here) to correctly install those packages. A saner approach (thinking of > embedded development and the memory limits )is installing them in a different > directory from which you can make an image to download on your board. This is the difference between 'mini-debian' and 'emdebsys'. mini-debian is a proper working system that can control it's own packages (quite possibly using ipkg rather than dpkg because it's great deal smaller). If you want a system without this overhead then you use emdebsys to take the appropriate files from emdebian/mini-debian. I think we have to be clear about this distinction. Emdebian can't be everything to everybody. There is a differnce between small systems that can manage their packages and tiny systems that can't. Ultimately emdebian can cater for both these needs, but not with the same tools. In this thread we are primarily discussing the 'small system' option. Of course if you think I'm wrong about this and we should be conentrating on tiny systems first (i.e making emdebsys better or completely different) then fair enough, but we need to be clear about these things otherwise we'll all get tied up in confusion talking at cross-purposes. > PS: I'm doing a master thesis about this stuff, and have worked out an > approach. > However it is not finished. But I have exams now so not very much time > either. I > already made a testing suite and docs which will be published when they have > been reviewed and approved by the people which are helping me on this > (currently > this reviewing is being done, hopefully I can point at it by the end of the > week). I look forward to it. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
