On Jun 21, 2008, at 12:05 PM, Denis Washington wrote:
What if the transaction fails? register_package() would have returned
without error although the registration was unsuccessful then, and all
files would already be installed.
What if you've added a header, but your daemon exits before
successfully computing and adding RPMTAG_SIZE withthe
_close_package() method?
Same issue, sh*t happens. I'm just trying to minimize the window
where disasters occur because I _WILL_ have to do the support
even if your "Berlin API" code is flawed.
Note that there are no commit/apply transactions, and no
D == Durability as in ACID present with an rpmdb.
Wishing an rpmdb had ACID properties is not going to change
the status quo.
Too little: currently yes. Too late: no. Just my opinion. We both know
that our thoughts on this differ quite much.
I've been at RPM packaging for over a decade, you mebbe a month.
Wanna bet on whose opinion is correct? ;-)
My current interest in your code is disaster prevention, not
otherwise.
I welcome any motive if it improves code quality, so thanks anyway. ;)
NP. My life is hell when rpmdb's get hosed up. Doesn't matter whether
its a kernel mmap(2) flaw, an selinux policy-of-the-day typo, or a
python
script kiddies dain bramage.
The "Berlin API" is a recipe for disaster so far.
But I'm most definitely deeply and personally interested in not
having to do the necessary rpmdb maintenance post-mortem
if the implementation problems can be solved.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
