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.
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.
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.
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.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
