Previously Christian Hammers wrote: > > 1. strace can't handle more then 256 subprocesses, a limit you can (and > > will) reach when building packages. > really? I'll check it.
Trust me, I'm upstream maintainer for strace so I'm reasonably aware of its features :) > > 2. strace'ing an application can influence it: timings can change, > > things can fail subtle due to bugs in the kernel or strace, etc. > What subtle timings can change the *build* process of a package? Slight bugs in programs used in the build process; I've seen it happen. I also have a report of a program hanging if you strace it. Funnily enough that was noticed when somebody straced a package build. Could be an strace bug, program bug or kernel bug, but definitely very hard to track down. > > 3. current strace doesn't support following vfork and clone (except on > > ia64), so you can still have incomplete build dependencies. > That's what the vfork wrapper is good for - fork and vfork are the same > on Linux x86 (I can't prove it, see mailing list dpkg-mentors). That's not true anymore, and hasn't been for some time. Look at arch/i386/kernel/process.c and kernel/fork.c . > And remember that this is only a "suggestive" tool like dpkg-shlibdeps, > if your package is so strange that it really does not work you can omit it > and you can *always* add own dependencies - just like with dpkg-shlibdeps. True, but I would rather not add an option what I know will break things. Wichert. -- _________________________________________________________________ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
pgp1vFo6HIICf.pgp
Description: PGP signature
