[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Requires & Provides on -devel packages (Continued)

On Wed, Mar 26, 2003 at 04:01:43AM +0100, Dag Wieers wrote:
> On Tue, 25 Mar 2003, Jeff Johnson wrote:
> > On Tue, Mar 25, 2003 at 02:19:24PM +0100, Dag Wieers wrote:
> > > On Tue, 25 Mar 2003, Stefan van der Eijk wrote:
> > > 
> > > Creating a slim clean build environment for each package seems to be 
> > > overkill (to me). I simply don't have the resources. I have one fat clean
> > > build environment for each distribution.
> > 
> > Using the --bind option to mount to remount pieces of the build environment
> > readonly on a per-package build mount point isn't impossible.
> That's what I'm doing now. Together with chroot. But I'm not building a 
> build environment for each individual package (as was suggested).

Cool! That's the right thing to do, strace is a pig, and LD_PRELOAD won't
touch statically linked binaries, changes dependencies generated.

I'll have to take a look soon.

> > What's more, all build dependencies could then be accurately and automagically
> > generated by trapping open/exec calls at the file system layer.
> How would you trap it ? syscalltrack ?

There's PODFUK (Czech for "cheat"), kind of a loop back file system thingy,
that can be inserted as a file system type.

Steal the open call to log every file opened during a build in cache,
pass everything else through.

At end of build, convert files used to build dependencies. For package
deps, basically rpm -qf <filenames> } sort | uniq would do the trick,
although I'm sure some filtering will be needed.

> > > Building as a user helps you not to pollute your build environment, but 
> > > for each violation the build is halted. Compare this to rpmbuild telling 
> > > you only the first file from %files it cannot find ;)
> > 
> > Sooner or later you build as non-root and fix the package. Pollution
> > is a much nastier problem, as it can affect all, not just one, package(s).
> Don't let me be misunderstood ;) I'm fixing my packages, and my build 
> environments are not polluted. Soapbox is preferably used as non-root.


> > > Well, you could use the same techniques (overloading open()) to make a 
> > > list of all the requirements a build-process has. And list them for 
> > > inclusion or add them to the source-package automatically.
> > 
> > Yup, LD_PRELOAD has uses, but can screw up dependencies.
> I had that problem 2 years ago (with a socksified system). I even had a 
> bugreport about it in bugtraq. I don't know what has been changed, but now 
> my LD_PRELOAD libraries are not longer reported as dependencies.

Hmmm, objdump rather than ldd is used in find-requires?

73 de Jeff

Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []