On 6/10/2010 6:18 AM, Vadym Chepkov wrote:
> 
> On Jun 9, 2010, at 11:56 PM, Fabio M. Di Nitto wrote:
> 
>> On 6/10/2010 1:50 AM, Vadym Chepkov wrote:
>>> Hi,
>>>
>>> There are several issues with corosync spec file.
>>>
>>> - configure script should be called in %build, not in %prep section.
>>> - the macro used for init.d is wrong
>>> - chckonfig --add should be called only when rpm is installed, not during 
>>> upgrade, because it will overwrite the custom set priorities
>>>
>>> I attached the patch:
>>
>> Not acknowledge.
>>
>> The %prep vs %build is not a requirement in any rpm based distribution.
>> configuring the tree is preparation of the tree and not build (but we
>> can argue about this forever as it goes down to how you see at the whole
>> build process).
> 
> If one would want to see what the source code is getting compiled he would 
> execute:
> 
> rpmbuild -bp --nodeps corosync.spec
> 
> If you put configure in the prep section it would go through commotion of 
> looking for build tools and fails when none of the build tools are installed 
> and all that for no reason.
> 
> http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
> suggests to run configuration script in the build section all Redhat rpms I 
> saw behave this way
> I still remember what R in rpm stands for.

I guess we will need to agree to disagree.

The %prep Script
[snip of the obvious irrelevant bits]

# Perform any other actions required to get the sources in a
ready-to-build state.

[snip]

The %build Script

The %build script picks up where the %prep script left off. Once the
%prep script has gotten everything ready for the build, the %build
script is usually somewhat anti-climactic — normally invoking make,
maybe a configuration script, and little else.
^^^^^^
[snip]

Either way, let´s not waste time or energy here. As long as it works, I
care little.

>>
>> As we discussed via email, caging the call to chkconfig only solves part
>> of the problem you reported and not all of it. The correct solution is
>> to ship a specific init script for rhel5.
> 
> It still preserves custom priorities set by administrator.
> If he wants to revert to default he would run
> 
> chkconfig corosync resetpriorities

it doesn´t protect you from:

chkconfig corosync off
chkconfig corosync on

i am not saying your patch is completely wrong. I am saying i´d like to
see a proper and complete fix including correct rhel5 values as you
reported them not to be correct on top of the protection.

Fabio
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais

Reply via email to