[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: native vs emulated configuration



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: pgpSUbeBiT9Rl.pgp
Description: PGP signature


Reply to: