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 [EMAIL PROTECTED] 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 ______________________________________________________________________ RPM Package Manager http://rpm5.org LSB Communication List rpm-lsb@rpm5.org
