On Jul 29, 2007, at 12:47 PM, Ralf S. Engelschall wrote:

> On Sun, Jul 29, 2007, Jeff Johnson wrote:
>
>>> Jeff, can you investigate on this remaining issue, please?
>>
>> Already investigated.
>>
>> Guaranteeing that a rpmdb is closed gracefully under all possible
>> conditions is a fool's implementation.
>>
>> Consider segfaults, kill -9, reboot, more.
>>
>> So stale locks are detected and cleaned on next invocation instead.
>> [...]
>
> Sorry, I personally cannot fully agree here, Jeff.
>

OK, we disagree ;-)

> Yes, I agree, it is perfect that RPM is really able to detect and
> cleanup in case of any aborts it has not under its own control (like
> segfaults, kill -9, reboots, etc.) I really like that this is the  
> case.
>

AFAICT, insque on a new development platform was the root cause
for the exit. How is detect/cleanup to be achieved in that environment?

> But, no, IMHO this is not a general excuse for not doing any clean
> program terminations in case of an abort/error which RPM _HAS_ under
> full control. I personally consider this just lazy programming.
>

OK. So make a postive suggestion. So far you've asked me to  
"investigate", and
are implying that I'm "lazy".

The rpmdb close occurs when a rpmts is released.

Your --erase has managed an exit where rpmtsFree() did not occur, or  
because there
is an additional reference count that could be displayed with -- 
rpmtsdebug if a reproducer
was known.

Boogered insque on a development code base on a brand new platform
is not exactly a reproducer that is meaningful.

Nor is mmap(2) fubarage in a linux kernel.

> Sure, at least on the next invocation, the result is effectively the
> same. But to make a comparison: just because a reasonable Unix  
> platform
> removes all files in /tmp during booting doesn't mean program can stop
> removing their temporary files at all, etc. Or just because you have a
> journaling filesystem also doesn't mean that you now should prefer to
> shutdown your system by breaking into the kernel debugger and  
> triggering
> a manual panic.

Details and/or additional suggestions please, I'd like not to be "lazy".

73 de Jeff