On Sat, 2008-06-21 at 11:44 -0400, Jeff Johnson wrote:
> On Jun 21, 2008, at 11:19 AM, Denis Washington wrote:
> >
> > The LSB specification says RPMTAG_BASENAMES and friends should be  
> > used,
> > so the choice is pretty clear.
> >
> 
> Good. It took bloody years to get that "choice" into the "LSB  
> Packaging Standard".
> 
> >>>> The transaction set (and the underlying configuration/rpmdb  
> >>>> handling)
> >>>> cannot be scoped within the individual methods if you are going
> >>>> to compute and add RPMTAG_SIZE lazily in _close_package().
> >>>
> >>> I don't know what you mean here. I use a separate transaction set  
> >>> for
> >>> _register_package() and _close_package(), closing after each  
> >>> function.
> >>>
> >>
> >> What I mean is that the _register_package() method constructs
> >> what you are calling a Header, and calls rpmdbAdd().
> >>
> >> Then the _close_package() method comes along later, reopen's
> >> an rpmdb, adds RPMTAG_SIZE, and rewrites the header.
> >>
> >> There's a racy window between your 2 method calls that will lead
> >> to very hard to diagnose issues. Adding RPMTAG_SIZE in
> >> the _register_package() method turns _close_package() into
> >> a no-operation needed stub, and otherwise avoids statefulness.
> >
> > True. But the problem is that the complete header cannot be created in
> > _register_package() as the package files are still missing. And  
> > doing it
> > in _close_package() kills the guarantee that a successful run of
> > _register_package() means a successful package registration - we only
> > know if we were successful after rpmdbAdd().
> >
> 
> So keep the header around until "complete", then do rpmdbAdd(),
> which will need a transaction and more.

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.

> The raciness I've pointed out has everything to do with  database <->  
> daemon
> interactions, nothing at all to do with rpmdb specifically.
> 
> >>> P.S.: For follow-ups of general interest, I recommend you to reply
> >>> on packaging@lists.linux-foundation.org. You can subscribe here:
> >>>
> >>>   https://lists.linux-foundation.org/mailman/listinfo/packaging
> >>>
> >>
> >> I will not reply on the packaging list, having received hostile
> >> threats there
> >> in the past.
> >
> > Unfortunate. I hope you'll at least follow the discussion over there.
> >
> 
> I follow, yes. Nothing that I haven't heard for years and years sadly.
> The window where LSB Packaging might have made a difference
> for Linux closed years ago, the "Berlin API" proposal was already too
> little and too late. JMHO ...

Too little: currently yes. Too late: no. Just my opinion. We both know
that our thoughts on this differ quite much.

> My current interest in your code is disaster prevention, not otherwise.

I welcome any motive if it improves code quality, so thanks anyway. ;)

Regards,
Denis