Re: Emdebian 'shrunken debian scheme'
+++ 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...
> 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
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
(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
> 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.
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/