Re: native vs emulated configuration
Hi,
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.
> 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'm really bad at choosing names. I would be really glad if somebody
could suggest one that is fitting better.
> 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.
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.
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.
But you are right - it is possible to run multistrap first, and then a
postprocess command to achieve the same by using saving and loading
features of fakeroot.
> 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.
I apologize again for my wrong usage of the terminology. I did not
intend to.
> 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.
> > - create tarball o to preserve symlinks of fakechroot correctly,
> > 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.
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.
> 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.
I dont mind. And I'm not expecting anything. I was just writing down
some of my thoughts about the matter.
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.
> I am utterly opposed to adding any emulation support to multistrap. It
> has nothing to do with actually generating the rootfs.
Again I apologize for misusing the term "generating rootfs". I was so
far under the wrong opinion that this term was including its
configuration as well.
That the only thing that is needed is a post processing tool instead of
a wrapper is true and I will think about this idea. I just worry about
the overhead one has to do with manually saving and then loading a
fakeroot environment for this to work instead of just calling one
wrapper with fakeroot.
I'm sorry to have angered you with my ignorance. It was not my goal to
do so. I also did not want to impose anything onto multistrap and I
thank you for making your point of view clear for me. I now know much
better about the terminology used by you.
cheers, josch
Reply to: