Re: native vs emulated configuration
(Sorry for reactivating an old thread)
Am 08.07.2011 20:27, schrieb Neil Williams:
On Fri, 8 Jul 2011 19:23:11 +0200
Johannes Schauer<firstname.lastname@example.org> wrote:
This is about configuring a prepared rootfs under emulation, nothing
more and nothing to do with multistrap or debootstrap.
Personally, I think that a tool which does emulated configuration of a
rootfs is and should be entirely separate from multistrap. I don't
think polystrap is the right name either, it isn't about the
bootstrapping, it's about configuration under emulation. I have never
wanted to rely on emulation and I want no part of such support.
I still use my Makefileset to create and reconfigure armel and powerpc32
rootfs on my amd64 host. Most of the packages could be configured fine
using the qemu-static trick.
Personally, I think debian live is the correct piece of software to
preconfigure a rootfs which was set up with multistrap. So multistrap
can concentrate on what Neil mentioned: No further features and hacks in
multistrap besides the main funtionality.
Be open and honest about what this is trying to achieve. It takes
something which has already been created and then operates on it under
emulation. It's a post-process, not a wrapper and it's emulated
configuration, not a bootstrapping process.
Multistrap was on the RFC list in the debian live wiki (and see ).
I have long argued that this has no place in multistrap. I know Wookey
disagrees but this analysis has only proved my point - there is nothing
you need adding to multistrap. All that is needed is to post-process
what multistrap can provide and you're choosing to do that under
emulation, others choose to do it natively. Either way, that is best
done with a separate tool/process.
Like debian live.
So I vote for removing setupscript and configscript option in
multistrap.conf. After that what I see, this can be reached with the
post-processing tool (correct me if I'm wrong).
Hooks are the one feature of multistrap which are most likely to be
removed or fundamentally redesigned. Don't depend on this support. It
may disappear during DebConf11.
My two cents.