Re: Embedded and ARM Debian Sprint
Guys:
Sorry for coming late to this thread. Just my thoughts:
Openembedded vs. Debian:
1. I have never succeeded in getting OE to work, after multiple
attempts. Even following to the letter instructions by others that
claim success. I'm not new at this. OE is far less stable than
Debian.
2. Debian's package-based model works much better for embedded
development work than OE's monolithic, recipe-based approach.
Debian's biggest advantage is that the package and source management
tools keep the policies for building vs. installing packages neatly
separated.
3. If you want images to come out of a Debian repository, what is
needed is a debootstrap-like utility. Or better yet, use debootstrap
in its current form and then use utilities like mkfs.jffs2 to convert
the output directory into a filesystem image for the embedded target.
That gives me total control over how the image is constructed, without
having to deal with a huge and time-consuming "recipe".
In short, what Debian has today is pretty darned good for embedded
work. I have been using Debian almost exclusively for embedded work
for nearly five years now. I have pretty much forgotten how to build
a cross compiler and uClibc+Busybox root filesystem.
On supporting architecture variants:
1. Maintaining separate repositories for ARM11, A8, etc.-optimized
packages really isn't a big deal. The Debian package repository tools
make this pretty darned easy, in fact.
2. The really popular variants will get official Debian architecture
names, anyway, thereby eliminating the problem.
3. Keeping optimized packages in a separate repository makes it
absolutely clear which packages have been optimized. MD5 sums and the
like can be used after-the-fact to verify that the package on a
machine is indeed the package you intended to be installed.
In other words, I really don't see where the current system fails
except for the convenience of having your particular variant already
supported by Debian.
On supporting truly small embedded systems:
1. I love the idea of a Debian system based on uClibc rather than
glibc. But I know that's a lot harder than it sounds.
2. The package manager databases are a substantial contributor to bulk
on highly-optimized systems. If dpkg had an option to purge some or
all of these databases, the footprint of the system would go down
considerably. (The source and package lists can be easily
regenerated; blowing away the list of currently-installed packages
would be unrecoverable, methinks).
3. I haven't tried it myself, but dpkg's --admindir and --instdir
options (or --root) might be useful for keeping bulky databases and
such out of a soon-to-be filesystem image in the first place. I
wonder of debootstrap could support those?
4. To me, the one of the beauties of emdebian Grip is that it merely
"cleans up" a lot of Debian packages. That's a benefit to both
embedded systems and Debian as a whole--- if those cleanups can get
pushed back upstream, anyway.
5. A big chunk of emdebian work, IIRC, involved dealing with
configure scripts that didn't understand "armel". That's a
shortcoming of the upstream source code, and doesn't reflect a problem
with Debian proper. So the fact that emdebian took a lot of work to
get going isn't because Debian is currently a poor choice for embedded
work--- quite the contrary, in fact.
If you ask me, the reason that Debian doesn't get more play in
embedded work is because the people who know how to do it are too busy
doing it to put together the necessary documentation for others to
follow! (That's my excuse, anyway). I think that even in its current
form, Debian is a huge benefit to embedded systems. We we're lacking
is exposure, not functionality.
I say "we" here somewhat incorrectly, since I'm not a DD. Someday
I'll get around to that. :)
Just my very tardy US$0.02,
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Reply to: