I see why you would like to have both chroot and fake root together.<br><br>One thing I don't understand is why the complex set of scripts to save state? Can't you just use one instance of fakeroot to run the entire build script under? And even if you do need to save state, that's what the -s and -i options are for.
<br><br> Alon<br><br><div><span class="gmail_quote">On 12/30/07, <b class="gmail_sendername">Shachar Shemesh</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="mailto:email@example.com">firstname.lastname@example.org</a> wrote:<br><br>> That being said, I don't really know why fake a chroot jail within<br>> fakeroot. I can understand why you'd like a userspace chroot jail, but<br>
> you won't usually need to fake root at the time.<br>><br><br>Actually, the two really come together. You use the same technology for<br>both chroot and fakeroot.<br><br>The real issue here, however, is testing embedded setups. I have a
<br>script that builds a directory structure (with different owners and<br>device files), that then gets automatically compressed into a SQUASHFS<br>image and saved. When you boot from it, it turns into a real<br>environment. It's real useful, however, to test whether this environment
<br>has all the devices, libraries and mounts that are required to, say, run<br>a certain program. The obvious solution is to chroot into it, and try<br>running the program.<br><br>With fakeroot I can run the entire build script as a regular user, which
<br>is great because I don't want to compile a whole system as root, I don't<br>want to leave a passwordless sudo on my machines, the script runs for so<br>long (ever times compiling of wxWidgets or glibc? They take a LONG time
<br>to compile) that a sudo with password expires, and that's before I start<br>talking about bugs in the DESTDIR mechanism, which, if run as real root,<br>may hose your entire system. fakeroot is ideal for those cases. I had to
<br>write a whole set of wrapper scripts around fakeroot to make it store<br>its state (i.e. - the lies it tells the programs) between runs in a<br>reliable way (and let me tell you, that stretches fakeroot's abilities
<br>to the limit).<br><br>However, once the environment is set up using fakeroot two things<br>happen. The first is that you don't want to use a real root in order to<br>chroot into it. You get used to good things :-). The second, and more
<br>important one, is that you cannot use a real root. All the files there<br>have the wrong owners and none of the device files are actual devices.<br>Sometimes it doesn't matter. Sometimes it does.<br><br>And that, actually, is the real reason fakeroot-ng was written.
<br><br>Shachar<br>_______________________________________________<br>Haifux mailing list<br><a href="mailto:Haifux@haifux.org">Haifux@haifux.org</a><br><a href="http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux">http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux