There's something that (as usual) bothers me with this brainstorm item. What are the benefits of most solutions?

Some of the benefits mentioned:
- Ability to install Debian packages
- Ability to build Debian or Maemo packages

... are IMO more easily done with a Debian chroot/Maemo cloned chroot, which has more benefits:
- ability to have a build environment that is not exactly the same version as your phone environment -- SDK release 0 in chroot for maximum compatibility package building vs PR1.1 in the phone
- ability to trash busybox and install bash and coreutils
- ability to install _unmodified_ ANY Debian release binary packages in Debian chroots
- plus ability to still boot your usual runtime system if the chroot is trashed for whatever reason
... vs IMO a minor tradeoff (more memory usage as you need to load both the chroot and Maemo libc + other libraries).


In my opinion the only one that has a clear benefit is solution #2 (since it means you'd be able to reflash the base firmware without reloading the installed apps!), but then it has quite an important tradeoff: even more Debian upstream compatibility is lost. Yes, changing a package's prefix is not 1-2-3: from all the packages I've ported to Maemo, 50% had some kind of hardcoded path.
I don't mind having to do this since I can report those to upstream, and getting those fixed is always nice, so solution #2 gets my vote (even if it clearly contradicts the brainstorm subject since it actually decreases debian compatibility).


And again I mention the recent improvements in the optifier. The idea is that a developer doesn't even have to know that the autobuilder is optifying.

Also, none of the options save for #3 guarantee that end users won't get their rootfs filled somehow. Then again I'm biased somehow since I've never managed to fill mine.