On Friday, November 02, 2007, at 03:43PM, "Mark Hatle" <mark.hatle@windriver.com> wrote:
>Two items from extensive use of "fakeroot" and "fakechroot" (from Debian).
>
>fakeroot has some many gotcha's.. it in essence has to be built to match
>the glibc that it will be overriding.  There are a million and one
>overrides.  We've recently been fighting a problem where building
>fakeroot for RHEL 4 won't work on Fedora 7.. because Fedora 7's glibc
>has additional interfaces that didn't exist in RHEL 4..  so the problem
>growns...
>
>The fakechroot issues are quite as bad, but there are still some
>problems.  The biggest of them is the behavior where a chroot runs and
>the cwd doesn't change.. but PATHs and related now reference the new
>root.  So this isn't trivial either.
>
>My best recommendation at this time is to use the debian
>fakeroot/fakechroot and document for people how to use them to achieve
>what they want.  I'm not sure integrating them into RPM is worth the
>effort.. (or more to the point the maintenance headaches!)
>

You were the originator for the feature request of handling fakeroot
within rpmlib. All I'm doing is fleshing out the details of an implementation
within rpmlib. Overriding weak symbols from glibc for system calls,
while not rocket science, does have associated costs, such as interversion
incompatibilities, as you have pointed out.

Meanwhile, for something as fundamental in rpm as non-root user installs, I'd rather
have an implementation directly in rpm rather than depending on external
functionality. fakeroot also won't Just Work if rpm is statically linked iirc, and
static linking saved my butt several times in the last year after I inadvertently
trashed glibc. YMMV.

Meanwhile, emulating chroot and getcwd in userland is likely of more theoretical, rather
than practical, interest to rpm at the moment.

73 de Jeff