Going back and forth between choices, I've finally decided to leave
these lines in,
only changing \; to \+ in finds to fork chmod (thanks to Alan's comments).
The updated webrev is at: http://cr.opensolaris.org/~dm223115/cvs.webrev/
Note: this is for cvs-1.11.23. Thanks to Steven M. Christensen, who
pointed out that
a newer version was available.
- Denis
Mike.Sullivan at sun.com wrote:
> >From Denis.Migounov at sun.com Wed Feb 11 10:24:51 2009
>
>
>> What's your word on it?
>>
>
> It's sounding to me like the best thing to do is leave them alone,
> but if you want...
>
>
>> Is it the correct way to do it?
>>
>
> there are many ways.
>
>
>> Actually, I've
>> tried it,
>> and all files and directories in the unpacked sources do have read
>> permissions
>> for everyone.
>>
>
> then it's probably ok. I think as I said before the the problem
> shows up when somebody else does a teamware operation that walks
> over the extracted files, so you could just try a bringover -n from
> your built workspace as well. And in fact that's what I care about -
> I don't want 'wx update' or a bringover to a built workspace to fail,
> so if you really want to be sure that's the best thing to check.
> I think it's mostly directories too not files, teamware gets upset
> if it can't cd into a directory. I think.
>
>
>
>> Also, how do I go about checking whether this line is really required:
>> find . -name core -exec rm -f {} \;
>>
>
> as I said, that line is to delete any expected core files that
> happen when configure runs. So one way would be to see if there
> are any core files in your build directory after configure runs :)
>
> though I don't remember if there were any that _sometimes_ happened.
> So I'd probably just leave that line, it's not like these finds are
> adding much to build time.
>
> Mike
>
