Re: Emdebian 'shrunken debian scheme'
hello,
Quoting Wookey <wookey@aleph1.co.uk>:
> +++ 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
Reply to: