[SSSD] [PATCH] Fix ini_config unit test

Dmitri Pal dpal at redhat.com
Wed Apr 14 16:00:55 UTC 2010


Stephen Gallagher wrote:
> On 04/14/2010 11:38 AM, Dmitri Pal wrote:
>
>   
>> Why chmod done from the UT itself?
>> It seems that the build framework should probably take care of this and
>> this
>> should be enforced in make check in make rather that from UT source code.
>>     
>
> No, it's not up to the build framework to care if this file has a 
> particular permission. It's our responsibility to set it. The build 
> system is designed so that when running 'make distcheck' we guarantee 
> that we're not writing to the $srcdir.
>
> I've explained this before, but here's a refresher:
> The gnu build system differentiates between the build directory and the 
> source directory, internally. This is done so that you can do parallel 
> builds with different configure flags (or architectures) based on the 
> same source directory.
>
> If you run configure from the source directory, then $srcdir==$builddir, 
> otherwise $builddir is set to your current directory. You tend to 
> develop in an environment where $srcdir==$builddir.
>
> make distcheck guarantees that when $builddir != $srcdir, a build does 
> not modify the contents of $srcdir. It tests this by extracting the 
> sources, and then performing 'chmod -R a-r $srcdir'  If the sources are 
> designed correctly, a build should still complete because all WRITES 
> should occur in the $builddir.
>
> Your unit test is a special case. It's safe to manually reset it to 0664 
> because we know that there's no data actually being written to it. It's 
> just needed to have those permissions for the access check test to be 
> run. So in this particular case, we know it's okay to set the mode 
> (because it won't have a negative impact on parallel build trees)
>   

I understand all this. And I am not arguing about what you described.
I just seems logical to me to have the chmod command in the Makefile
to change the permissions back after build did its chmod rather
than in the source code of the unit tests.
And what I was asking is that "is that my thinking is an old school?"
It is more for my education than anything else.

Ack.


>   
>> At least that how such things have been done in the past. Is it a right
>> way of
>> doing such things? I just do not know...
>> IMO it seems it does not belong there but if this is how it is supposed
>> to be I will buy it. Do we need to check the result of the chmod and
>> exit if it failed?
>>
>>     
>
> We could check for it, but it's really just overkill in a unit test. If 
> it fails, then immediately thereafter the permission check will fail 
> loudly. It should be easy to track down.
>
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list