I see why you would like to have both chroot and fake root together.<br><br>One thing I don&#39;t understand is why the complex set of scripts to save state? Can&#39;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&#39;s what the -s and -i options are for.
<br><br>&nbsp; Alon<br><br><div><span class="gmail_quote">On 12/30/07, <b class="gmail_sendername">Shachar Shemesh</b> &lt;<a href="mailto:shachar@shemesh.biz">shachar@shemesh.biz</a>&gt; 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:alon@8ln.org">alon@8ln.org</a> wrote:<br><br>&gt; That being said, I don&#39;t really know why fake a chroot jail within<br>&gt; fakeroot. I can understand why you&#39;d like a userspace chroot jail, but<br>
&gt; you won&#39;t usually need to fake root at the time.<br>&gt;<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&#39;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&#39;t want to compile a whole system as root, I don&#39;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&#39;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&#39;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&#39;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&#39;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
</a><br></blockquote></div><br>