On Fri, 8 Jul 2011 19:23:11 +0200 Johannes Schauer <j.schauer@email.de> wrote: This isn't about not having root access, it's about using emulation which only affects one stage, the configuration. This can be done quite easily without needing emulation, provided that the device can be booted into an environment which supports some form of chroot. Wookey wrote most of the scripts which do this for one particular device which was designed to provide just such an environment. I still use that system and I disagree with Wookey that this has anything to do with multistrap. It was working long, long before multistrap was even written. This is about configuring a prepared rootfs under emulation, nothing more and nothing to do with multistrap or debootstrap. > wookey was recently talking about the possiblity of extending multistrap > with some additional functionality so that a wrapper like polystrap is > not necessary. 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. > By going step by step through the things that polystrap does, let me > list what would have to change in multistrap to make it build foreign > rootfs without superuser priviliges: Multistrap already does all of this, the only thing for which some people might want emulation is configuration. That's device-specific. There's no reason to fold that into multistrap. You've noted no changes necessary prior to the configuration stage. You don't need a wrapper, you need a post-processing tool which can take the foreign rootfs created by the unchanged multistrap and then process it to perform configuration under emulation. 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. > - dpkg --configure -a > o this is done by multistrap already as well but it is only done > when building for native architecture > o also, chroot is used with no possibility to use fakechroot > instead > (!CHANGE!) 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. > - run some more hooks > o also done by multistrap (NO CHANGE) 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. > - create tarball > o to preserve symlinks of fakechroot correctly, this has to be done > with a fakechroot call (CHANGE) Or simply do this stage yourself. tar -czf isn't hard. > To summarize: hooks can do most of the stuff that polystrap does right > now. Even the rootfs tree that is currently copied in polystrap can be > dynamically created by hook scripts already. What multistrap would need > to allow would be to run the package configuration step for non native > targets as well and make it possible to use fakechroot in this step and > in the tarball creation step. Small tools doing small tasks well. Not huge monoliths. Write the post-process emulated configuration tool and don't expect changes in multistrap for emulation support. It's a "won'tfix". Beyond the scope of the package. Unsupportable. Unnecessary. Feature-Bloat. > Until all this is fixed it might not be desirable to have the "building > foreign rootfs without superuser priviliges" functionality in multistrap It is not about root access, it is about whether a specific device supports a method of booting which allows the rootfs to be mounted so that dpkg --configure -a can be run natively, or whether the configuration has to be emulated. "building foreign rootfs without root access" already works - depending on device-specific support. You're looking for emulated configuration, nothing to do with generating the rootfs itself. The question is whether to do native or emulated configuration - that's the only thing to decide. If your tool wants to support emulation, fine, others can carry on using native and no changes are needed. > at all but consider this email just as a short collection of ideas from > my side. Just a proposal to maybe discuss the possiblity of a future > extension of multistrap instead of just another foo-strap. Just be honest about what you're actually providing: qemu-config Nothing is missing from multistrap to build a rootfs without root access, there are already build snippets which use fakeroot to prepare the rootfs and then configure natively. The whole root access thing is misdirection and it has nothing whatsoever to do with multistrap. You can create the rootfs to be configured under qemu just as easily using debootstrap, cdebootstrap etc. I am utterly opposed to adding any emulation support to multistrap. It has nothing to do with actually generating the rootfs. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp3CVlJLP9Ha.pgp
Description: PGP signature