hello, Quoting Wookey <[EMAIL PROTECTED]>:
> +++ 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. > </snip> > 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. > > There already _is_ an emdebian naming scheme, described at the top of the > gcc > page: > http://www.emdebian.org/distrib/gcc.html > Didn't notice that one. > (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? I meant in a sense by going for uclibc (which is an excellent choice) only, it would make it hard to compile the sources against other libraries like newlib,... > > 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. I was thinking in the line of a more Debian embedsys, in a way it would use adapted Debian packages. But nonetheless I was already playing with the thought of an mini-debian with uclibc too for older, weaker systems now that GNU/Linux has grown quite heavy for machines from a few years ago (thinking old 486's or early pentiums) Maybe we should make a different thread for each approach, then look at what can be used for both (like they both need a small package, with no docs etc...) and what are the big differences. I know that on first sight it is splitting forces, in the long run we could have a part (maybe the base packages with a slightly different build-target) in common were everybody works on, and seperate more specific ones. greets, Philippe | Philippe De Swert -GNU/linux - uClinux freak- | | "GNU is the way" | | Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/ -------------------------------------------------------------------------- Gestuurd via het webmailsysteem van het De Nayer Instituut: www.denayer.be
