On Jul 29, 2007, at 1:51 PM, Ralf S. Engelschall wrote:

> On Sun, Jul 29, 2007, Jeff Johnson wrote:
>
>>> 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?
>
> Well, the Autoconf glue for insque(3) just triggered the error at
> rpmio/mire.c:131:mireRegcomp(). But the error is unrelated to insque,
> of course. It could also happen if any particular regex is not  
> accepted
> by regcomp(3). But even this is too particular as the actual problem
> is more that RPM uses a plain call to rpmError() (= rpmlog()) in case
> of any problems but rpmlog() itself does not give the rpmdb code any
> chance to cleanup. I know, it is rather complicated to do proper  
> cleanup
> handling here. Else you would have already implemented it, of course.
>

Yes better error handling could be done.

I've asked for platform patterns that might be used intelligently on  
rpm-devel,
both persusasions.

I've helped several write patterns, and have offered up what I used  
for testing
on several occaisions.

Until the platform paradigm is fully established, and rpmrc handling  
is gone,
handling errors while loading patterns is lower on priority list.

>>> 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".
>> [...]
>> Details and/or additional suggestions please, I'd like not to be  
>> "lazy".
>> [...]
>
> Hey, Jeff, I said, "lazy programming" above, not that I consider
> _you_ personally as "lazy". That's really different kinds of
> lazyness, of course. With "lazy programming" I mean something like
> "deferred handling" during programming. You know the terms like "lazy
> allocations", etc? That's what I talked about. Sorry if you treated as
> offensive. This was not my intention.
>

I've considered atexit and other schemes, have chosen the
current polling scheme for rpmdb closing instead, largely because
there are other portability considerations.

I'm open to suggestions.

Meanwile, the Berkeley DB hatred is palpable and experienced by me  
daily ...

>> 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.
>
> I think RPM internally needs to register cleanup codes during its
> processing and in case of an rpmError() the registered cleanup  
> callback
> functions have to be executed to give the code a chance to perform
> proper cleanups like closing the rpmdb, etc.
>

I'm not averse to registration. I can tell you the dbcursor and r 
[pmdb chaining underneath
refcount'ed rpmts->rpmdb with lazily instantiated signal handler was  
exceedingly difficult.
to get right.

And no matter what, the universe(s) of error handling are
orders of magnitude larger than the universe of rpm functionality,
and at some point, I don't bloody care.

Somehow all of rpm development has gotten turned around into
backward looking error handling and legacy compatibility on a buttload
of platforms where rpm is hardly used with oddball features like spec  
file
style, multilib, selinux, --prefix, and other "stuff" like pubkey  
rings, run-time
discovery of macros, network transport (or not), signature  
verification (or not),
NPTL (or not), lua (or not) and ... and ... and ...

There's no new rpm features in any of the above. The implementations  
happened
years ago, like it or not.

73 de Jeff