[CentOS-devel] Mock patch speeds up 'mock init' to 5 Seconds from cache (linked, rsync'd)

[Jeff Johnson]

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