You probably could have change \; to \+ here to ...
   37         @find . -name core -exec rm -f {} \;

And just being picky, you might want to make the CDDL HEADER and around 
conform to the layouts in ....
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/prototypes/
(see http://wikis.sun.com/display/SFWNotes/Package+writing+guidelines)
for ...
   usr/src/cmd/cvs/install-sfw
   & usr/src/cmd/cvs/Makefile.sfw
   & usr/src/pkgdefs/SUNWcvs/pkginfo.tmpl

Otherwise it looks good to me :-)

paul


Denis Migounov wrote:
> 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
>>   

-- 
----------------------------------------------------------------------
Paul Cunningham
Software Engineer
Tadpole Business Unit

Reply via email to