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

Re: native vs emulated configuration

On Sat, 9 Jul 2011 09:55:59 +0200
Johannes Schauer <j.schauer@email.de> wrote:

> On Fri, Jul 08, 2011 at 07:27:17PM +0100, Neil Williams wrote:
> > This is about configuring a prepared rootfs under emulation, nothing
> > more and nothing to do with multistrap or debootstrap.
> Let me apologize for not being clear in the discussion so far. I was
> consistently misusing the terms "bootstrapping", "configuration" and
> "emulation" and mixing them freely. You made that clear several times in
> your message.

That's OK. Clarity is important in these things.

> I did it in form of a wrapper for the following reasons: The most
> important reason is, that to have file permissions work correctly, it is
> easiest to execute everything in one single fakeroot call. fakeroot
> allows to save and load environment information but it is tedious to do
> so when building and configuring the rootfs with several commands.

True, fakeroot can be a pain like that.

Life is so much simpler with sudo, once configured.

> Another reason is, that arguments like arch, directory, suite and mirror
> are passed to multistrap and other subcommands without having to specify
> them more than once.

Another option is to have multiple files because the only option which multistrap needs on the command line is the filename. Everything else can be specified inside the file.
> > 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.
> No multistrap hooks are used so far. So this is no issue.

Ah, OK. That's good to know. I'm not sure how hooks should work and I'm not at all sure that the current hooks are usefully placed. The lack of people actively using them hints at the same thing. The hooks, if they are to be retained, need to be redone.
> again, the reason was fakeroot. it is much easier to only execute one
> single script under fakeroot instead of manually having to handle
> environment saves on the commandline. Additionally, the tarball has to
> be created from inside a fakechroot as well. Since this tarball will be
> created in the root, is has to be moved out of there as well. An
> additional step that is automated right now.

Hmm, why would the tarball need to be created from inside a fake chroot call? Look at the multistrap tarball functionality, it packs up the tarball from the directory above. tar has good support for this kind of operation.
> To me multistrap already is a kinda huge. This is, compared to what it
> does at its core which is just one apt-get call with a number of
> arguments allowing it to download and unpack packages.


(ok, it's two apt calls, one to update and one to download, each using the same arguments but still...)


Neil Williams

Attachment: pgpoqIBLGlrCq.pgp
Description: PGP signature

Reply to: