On Sat, 2008-06-21 at 10:55 -0400, Jeff Johnson wrote:
> On Jun 21, 2008, at 10:32 AM, Denis Washington wrote:
> 
> >
> > Thanks for taking a look. I am really new to programming RPM, so any
> > help is greatly appreciated.
> >
> 
> 
> >> In general, what is being called a Header does not include sufficient
> >> metadata to be casually installed in an rpmdb. You can/will create
> >> cause existing rpm deployments to segfault if you proceed with
> >> the header as constructed in this implementation.
> >
> > I already figured that I might not have added all mandatory  
> > metadata to
> > the header. Unfortunately, I didn't find any documentation on which  
> > data
> > must be present. Can you point me at the right direction?
> >
> 
> The tag descriptions in the LSB packaging standard are included
> as an appendix to the "RedHat RPM Guide" which is available
> somewhere in Fedorable land. The text is also maintained somewhere
> within LSB as well.

Ok, I'll have a look at those, that will most certainly help. A quick
look already tells me that there is still a lot to do..

> >> Look closely at the "LSB Packaging" documentation that describes
> >> tag content, paying particular attention to the content that LSB has
> >> chosen to call "MANDATORY". The fact that the header is in a rpmdb
> >> rather than a *.rpm package does not permit MANDATORY to be ignored.
> >>
> >> Adding both RPMTAG_FILENAMES  and RPMTAG_ 
> >> {DIRNAMES,BASENAMES,DIRINDEXES}
> >> is just wrong. One or the other should be done, not both.
> >
> > OK. Again, I didn't find any documentation on this, so I just filled
> > both. Which of them is preferred?
> >
> 
> RPMTAG_FILENAMES was abandoned by RPM in RHL 7.0 ~2000, but is mired in
> what is now known as the "LSB format".
> 
> You will have to choose which of the conflicting representations for
> file paths you wish to use. Including both is clearly a flaw, and worse
> than either.

The LSB specification says RPMTAG_BASENAMES and friends should be used,
so the choice is pretty clear.

> >> 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().

> > 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.

Regards,
Denis