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