[SSSD] [PATCH] Fix ini_config unit test

Stephen Gallagher sgallagh at redhat.com
Wed Apr 14 16:09:02 UTC 2010


On 04/14/2010 12:00 PM, Dmitri Pal wrote:
> 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.
>

Ah, I misunderstood that you were really asking "Does the chmod belong 
here or in the makefile".

Yeah, I think it belongs in the test. It makes much more sense (to me at 
least) that the test itself be internally consistent. I think putting a 
test-specific change in the build system is unnecessary.

Thank you for the review.

>
>>
>>> 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.
>>
>>
>>
>
>


-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



More information about the sssd-devel mailing list