[Freeipa-devel] import rpm causes failure during IPA caless install

[Jan Cholasta]

On 8.1.2016 15:44, Tomas Babej wrote:
>
>
> On 01/08/2016 03:31 PM, Lukas Slebodnik wrote:
>> On (08/01/16 14:14), Jan Cholasta wrote:
>>> On 8.1.2016 14:09, Martin Basti wrote:
>>>>
>>>>
>>>> On 08.01.2016 14:00, Martin Kosek wrote:
>>>>> On 01/08/2016 01:45 PM, Martin Basti wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> fix for ticket https://fedorahosted.org/freeipa/ticket/5535
>>>>>> requires to import rpm module
>>>>>>
>>>>>> This import somehow breaks nsslib in IPA
>>>>>> https://fedorahosted.org/freeipa/ticket/5572
>>>>>>
>>>>>>
>>>>>> We have 2 ways how to fix it:
>>>>>>
>>>>>> 1) move import rpm to body of methods (attached patch)
>>>>>> We are not sure how stable is this solution.
>>>>>>
>>>>>> 2) use solution with rpmdevtools proposed here:
>>>>>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00092.html
>>>>>> This should be rock stable but it needs many dependencies (rpm-python
>>>>>> too, perl)
>>>>>>
>>>>>> The second way looks safer, so I would like to reimplement it, do you
>>>>>> all agree
>>>>>> or do you have better idea?
>>>>>> Feedback welcome, please ASAP.
>>>>>>
>>>>>> Martin^2
>>>>> Since it's Friday, I invested 15 minutes to practice my C skills and
>>>>> use the
>>>>> python-cffi library to call rpm rpmvercmp library call directly
>>>>> (attached):
>>>>>
>>>>> $ python rpm.py 4.2.0-15.el7 4.2.0-15.el7_2.3
>>>>> 4.2.0-15.el7 < 4.2.0-15.el7_2.3
>>>>>
>>>>> This would not introduce any additional dependency besides rpm-devel,
>>>>> right? :-)
>>>
>>> Not rpm-devel, but rpm-libs (you should dlopen "librpm.so.3").
>>>
>> CentOS 7 has librpm.so.3
>> but fedora 23+ has librpm.so.7
>>
>> So if it is possible it will be good to avoid using specific vertsion.
>>
>> LS
>>
>
> Yes.
>
> I think it should be quite possible to not use specific version, the
> interface signature itself is not likely to change.
>
> Even if it did, the problem would be detected immediately with the most
> basic of tests ()installation&run).

If by "detect" you mean "SEGFAULT", then yes. But I don't think this is 
very nice way of detecting an issue.

-- 
Jan Cholasta