Fr�d�ric Leroy <[EMAIL PROTECTED]> writes:
> It would be much easier for anyone to make rpm with this ...
> Maybe i don't understand a trick which make theses unnecessary.
we already tried to use fakeroot, and we ran a lot of prolems
specially with devices. There is recently a discussion about that on
rpm-devel and look the answer of Jeff Johnson (rpm maintainnners) :
--=-=-=
From: Jeff Johnson <[EMAIL PROTECTED]>
Subject: Re: rpm and fakeroot?
To: [EMAIL PROTECTED]
Date: Mon, 6 Nov 2000 09:57:08 -0500
Mail-Followup-To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
On Sun, Nov 05, 2000 at 02:17:08PM -0700, Tim Riker wrote:
> Jeff,
>
> Have you ever looked at the fakeroot package that is used on Debian?
>
> http://packages.debian.org/unstable/utils/fakeroot.html
>
> basically fakeroot is loaded via LD_PRELOAD before running dpkg to do a
> package build. faked is a daemon that logs chown/chmod/getuid/etc events
> that require root privileges and then the fakeroot library makes it look
> as if these events actually happened. Hence when the files are packaged
> up, they have the intended user/group ownership and permissions without
> the user needing true root privileges. This seems a Good Thing and
> something rpm could really use. It will allow many packages to be built
> by non-root users without adding specific permissions in the Files
> section and without modifying the Makefiles.
>
> In fact I could see the possibility of implementing BuildRoot this way
> by just patching up all paths in open/access/etc calls. This would
> eliminate the need for Makefiles to deal with BuildRoot as well.
>
> Thoughts?
The issue of using LD_PRELOAD and fakeroot has come up before. The impediment
to using fakeroot is more historical than otherwise, as rpm does things
differently than dpkg, and so rpm packagers have not tried to use fakeroot.
FWIW, there are important reasons to use a BuildRoot above and beyond
ability to fake write(s) into directories without permissions, as build
systems can become polluted by broken software during installs. Having a
single directory with only files that are to be included in a package has
advantages as well, as one does not have to supply an explicit manifest
to each and every helper script, a simple find will often suffice.
Using LD_PRELOAD to trim leading BuildRoot paths is clever, but
1) assumes that all executables are shared, statically linked
executables will not conform.
2) assumes that all platforms implement LD_PRELOAD
I've been wrestling with a similar problem trying to automate BuildPreReq's.
There are 3 ways to intercept all open/execve calls performed during a
build that I've been able to devise:
1) strace using ptrace(2)
+ works for both shared and static executables
- very slow, as ptrace(2) does several context
switches on every system call.
2) LD_PRELOAD
- fails with statically linked binaries
+ runs adequately fast
3) PODFUK (Czech for "cheat"), basically a local NFS re-mount
that intercepts open/execve (and other) syscalls.
+ fast
+ works for all file access
+ efficiently caches info for post %install processing.
- requires build systems to support PODFUK software.
I'm currently leaning toward 3) ...
If do try a LD_PRELOAD approach to fakeroot, send me a patch, as there
will probably need to be several complimentary solutions to the same
basic problem to support the entire whore house of unix :-)
73 de Jeff
--
Jeff Johnson ARS N3NPQ
[EMAIL PROTECTED] ([EMAIL PROTECTED])
Chapel Hill, NC
--=-=-=
_______________________________________________
Rpm-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/rpm-list
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
