On Thu, 11 Nov 2010 10:29:38 -0600 Bill Gatliff <bgat@billgatliff.com> wrote: > 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. This is an ever-present sentiment. > 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". It is fairly trivial to set this up as the end-process of a multistrap operation with a simple wrapper. I'm wondering if this could be added to the main multistrap setup. It's a balance between endless configuration option availability and usability. > 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. A separate repository (or at least a separate component which is, effectively, much the same thing with the advantage that where sources are the same, the sources can be shared without duplicating files). > 2. The package manager databases are a substantial contributor to bulk > on highly-optimized systems. This is another reason to use components for splitting package lists by functionality, as used in Grip. Each component has it's own Packages file and by taking packages out of main/ and into debug/, doc/ etc means that the size of main/ is correspondingly decreased. > 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). Indeed. 'apt-get clean' IMHO should have a 'very-clean' step which removes this data as well. I think we should investigate that after the Squeeze release. (There have been enough changes in apt before Squeeze already...) > 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? Multistrap could potentially support those. This data is hard to regenerate, so it is more suitable for Emdebian Baked. apt data is trivial to reconstruct (once a network is available) but actually relies on the dpkg admin data for the reconstruction process. > 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. The big amount of work for Emdebian Crush involved getting the Debian packaging to understand cross architecture builds - understanding the dpkg-buildpackage -aarmel option - but 'armel' as a specific string / config was not the problem. The other big area of work for Emdebian Crush was using busybox instead of coreutils and dropping perl. That stage still doesn't work properly and is a significant barrier to making an Emdebian installation a lot smaller than Grip. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpoZkYQWgqY2.pgp
Description: PGP signature