On Jun 21, 2008, at 11:19 AM, Denis Washington wrote:
>
> The LSB specification says RPMTAG_BASENAMES and friends should be  
> used,
> so the choice is pretty clear.
>

Good. It took bloody years to get that "choice" into the "LSB  
Packaging Standard".

>>>> The transaction set (and the underlying configuration/rpmdb  
>>>> handling)
>>>> cannot be scoped within the individual methods if you are going
>>>> to compute and add RPMTAG_SIZE lazily in _close_package().
>>>
>>> I don't know what you mean here. I use a separate transaction set  
>>> for
>>> _register_package() and _close_package(), closing after each  
>>> function.
>>>
>>
>> What I mean is that the _register_package() method constructs
>> what you are calling a Header, and calls rpmdbAdd().
>>
>> Then the _close_package() method comes along later, reopen's
>> an rpmdb, adds RPMTAG_SIZE, and rewrites the header.
>>
>> There's a racy window between your 2 method calls that will lead
>> to very hard to diagnose issues. Adding RPMTAG_SIZE in
>> the _register_package() method turns _close_package() into
>> a no-operation needed stub, and otherwise avoids statefulness.
>
> True. But the problem is that the complete header cannot be created in
> _register_package() as the package files are still missing. And  
> doing it
> in _close_package() kills the guarantee that a successful run of
> _register_package() means a successful package registration - we only
> know if we were successful after rpmdbAdd().
>

So keep the header around until "complete", then do rpmdbAdd(),
which will need a transaction and more.

The raciness I've pointed out has everything to do with  database <->  
daemon
interactions, nothing at all to do with rpmdb specifically.

>>> P.S.: For follow-ups of general interest, I recommend you to reply
>>> on packaging@lists.linux-foundation.org. You can subscribe here:
>>>
>>>   https://lists.linux-foundation.org/mailman/listinfo/packaging
>>>
>>
>> I will not reply on the packaging list, having received hostile
>> threats there
>> in the past.
>
> Unfortunate. I hope you'll at least follow the discussion over there.
>

I follow, yes. Nothing that I haven't heard for years and years sadly.
The window where LSB Packaging might have made a difference
for Linux closed years ago, the "Berlin API" proposal was already too
little and too late. JMHO ...

My current interest in your code is disaster prevention, not otherwise.

73 de Jeff