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 [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
