Denis Migounov wrote:
>
> It does make feel safer just to leave them in. OTOH, I don't mind to
> check to
> see whether they are really required, I'm just know sure how I go about it.
I think it might be something like:
1. unpack the pkg's tarball (as done in Makefile.sfw)
2. Check *all* files and directories in the unpacked src have
'read' permission for 'everyone'
but you might want to check with Mike (as gatekeeper) that is correct
paul
>
> Paul Cunningham wrote:
>>
>>
>> Denis Migounov wrote:
>>> Colleagues,
>>>
>>> Now I'm really torn. How do I proceed with this?
>>
>> In my opinion - you should check if they are really required, and if
>> not delete them.
>> But if it makes you feel happier/safer leave them in as its an update
>> integration (rather than a new pkg).
>>
>> p
>>
>>>
>>> - Denis
>>>
>>> Mike Sullivan wrote:
>>>> Paul Cunningham wrote:
>>>>> Denis,
>>>>>
>>>>> Denis Migounov wrote:
>>>>>>
>>>>>> My comments are below.
>>>>>>
>>>>>> Paul Cunningham wrote:
>>>>>>> 1. usr/src/cmd/cvs/Makefile.sfw
>>>>>>> Line ...
>>>>>>> 37 @find . -name core -exec rm -f {} \;
>>>>>>> do you really need this - if so why? if not delete it
>>>>>>>
>>>>>>> lines ...
>>>>>>> 53 find $(VER) -type d -exec /usr/bin/chmod 755 "{}" \;
>>>>>>> 54 find $(VER) -type f -exec /usr/bin/chmod ugo+r
>>>>>>> "{}" \;
>>>>>>> again do you really need these? If not delete them.
>>>>>>>
>>>>>> These lines were in the Makefile used to build version 1.12.13 and
>>>>>> I just left them untouched.
>>>>>> Now, I talked to Maxim Kartashev (who ported 1.12.13) about why
>>>>>> they were put there originally,
>>>>>> and his answer was that these lines were needed to make sure that
>>>>>> all files had correct permissions,
>>>>>> since we (people who port the software) don't have control over
>>>>>> the the build process and never know
>>>>>> what might change in the scripts used to build the consolidation.
>>>>>
>>>>> I believe that those lines go back to the days of the CompanionCD
>>>>> and and are therefore historic (even before when I worked on the
>>>>> ccd and sfw stuff n years ago), they then got propagated from one
>>>>> pkg to the next next new pkg in the consolidation.
>>>>
>>>> that is a factor indeed.
>>>>
>>>>>
>>>>> They protentionally increase the sfw ws build time - so unless you
>>>>> know they are really required for your pkg I suggest you remove
>>>>> them. No recent new integrations into the sfw gate will have them.
>>>>
>>>> but the question is whether they are required. If they are not required
>>>> then yes, don't include them. But here's what they probably are for
>>>> from my memory:
>>>>
>>>> @find . -name core -exec rm -f {} \;
>>>>
>>>> that find was to delete core files that might be generated by
>>>> configure.
>>>> I think long ago when the ccd was created some configure runs would
>>>> indeed drop a few cores but it was normal. That may not be the case
>>>> anymore so it may not be needed. But you do need to make sure, as
>>>> nightly will look for core files when it is finished and tell you about
>>>> them, and that find was to delete any 'expected' core files so it
>>>> wouldn't always flag them.
>>>>
>>>> find $(VER) -type d -exec /usr/bin/chmod 755 "{}" \;
>>>> find $(VER) -type f -exec /usr/bin/chmod ugo+r "{}" \;
>>>>
>>>> find's like that that operate on the extracted source are sometimes
>>>> there in the sfw gate on purpose, often placed by me :) that's
>>>> because the tar file may contain directories that aren't accesible
>>>> by anyone but the user who extracts them (or perhaps files too) and
>>>> so if someone other than the builder is doing a putback -n/bringover/wx
>>>> operation that wanders the workspace it may well fail. This matters to
>>>> me because the gate workspaces do have to build as root still but I
>>>> do teamware operations on them as me so I sometimes hit this. However
>>>> you can indeed look at the tar file and see if you'd hit that kind of
>>>> thing (or just do a bringover -n from that built directory as someone
>>>> else and see if it gets upset).
>>>>
>>>> Mike
>>
--
----------------------------------------------------------------------
Paul Cunningham
Software Engineer
Tadpole Business Unit
