On Oct 28, 2009, at 1:34 PM, Shad L. Lords wrote: > Brian Schueler wrote: >> Therefore is the second copy named 'clean-cache-copy', which >> repairs the tainted files. The clean-cache-copy is _not_ linked >> and represent the original root cache. rsync syncs it to the >> 'linked-cache-copy' and ensures that the content is always the >> same before each mock build. > > And do all mock builds link against this copy? What happens if you > have > 3-4 builds going on at the same time? Are there any files that > would be > linked between chroots? (If all the chroots link to linked-cache-copy > then the answer would be yes) > If 3-4 builds are going on simultaneously, then the issue is "minimal suffcient" install to support all 3-4 builds, not anything to do with hard links. I would claim (but will not argue) that any build that is affected by having more than the "minimal sufficient" set of packages installed is broken for other reasons. > If you are just making a copy for each chroot then that isn't really > any > different then just modifying existing behavior but removing the > gzip on > the tarball > Yes. Exactly. Hard links are just less costly than gunzip on a tarball. And any package that changes a hard-linked file (your other msg) is broken for reasons that have nothing to do with whether hard links were used to populate a build system. Use chattr(8) after doing the hard links if you are worried about contamination. But some build, not the hard linking, is what was broken if pollution occurs. But yes, contamination of a stateful store also needs to be worried about. hth 73 de Jeff