[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: librpm / corrupt free list in an FD_t (help please)

On Tue, Jan 14, 2003 at 12:16:39PM -0500, Tristan Van Berkom wrote:
> Okie,
> 	I'm now porting to rpmlib-4.1 and wondering if 
> there is any documentation at all for the api changes.
> anything on the "eiu" stuff would be great. I noticed
> the absence of rpmReadPackageHeader; the header*();
> stuff looks about the same and the rpmTransactionSet
> stuff changed to the rpmts interface.

Here's what you want instead:

 * Return package header from file handle, verifying digests/signatures.
 * @param ts            transaction set
 * @param fd            file handle
 * @param fn            file name
 * @retval hdrp         address of header (or NULL)
 * @return              0 on success
int rpmReadPackageFile(rpmts ts, FD_t fd,
                const char * fn, /*@null@*/ /*@out@*/ Header * hdrp)
        /*@globals rpmGlobalMacroContext, fileSystem, internalState @*/
        /*@modifies ts, fd, *hdrp, rpmGlobalMacroContext,
                fileSystem, internalState @*/;

The major difference is that signatures/digest, header-only or header+payload,
will be performed. Do

	rpmtsSetVSFlags(ts, -1);
if you want the same behavior as previous. Note that -1 is a disable bit mask,
you can disable any of the signature digest checks if neeeded.

> 	I'm also wondering if I even need to get
> aquainted with theese "lower-level" sections of
> rpmlib. I noticed (in rpmqv.c) that running an
> install/erase/rollback is _very_ simple.
> Ok this is what I need to do:
> 	1- run something like the old `rpmDepCheck()'

Now called rpmtsCheck(), other arguments moved to rpmts methods, including
retrieval of dependency problems.

> 	  on a list of rpms (newer older removed
> 	  etc.... all at once).
> 	2- verify signatures and MD5 sums (nice to know
> 	  before a possibly needless reboot).

This is always done unless disabled or necessary value is missing.

> 	3- read information from the package header

Look carefully at rpmfi/rpmds methods, which are often easier to use
then the ageless but creaky headerGetEntry(), paricularly when dealing
with tuples of arrays of tag values.

> 	4- test-install upgrade/downgrade etc...
> 	5- perform actual software update.

The same Baroque'n 30+ bits that control what is now called rpmtsRun() are
there. Look for argument changes in rpmts methods, as a transaction set
is most everywhere now.

> So the question is: do I need to know the "EIU" stuff
> for that ? (probably for case 1, 2 and 3?)

Do you mean IAM_RPMEIU in rpmqv.c? That's purely a construct to build
executables with various subsets of rpm modes.

Ah you must mean lib/rpminstall.c, which has the EIU modes for rpm.
I wouldn't tie into rpmInstall(), but rather the operations,
	ts = rpmtsCreate();
	fd = Fopen(...)
	rpmReadPackageFile(..., &h, ...)
	rpmtsAddInstallElement(..., h, ...)

	rpmtsCheck(ts, ...)

FWIW, rpminstall.c is desperately in need of a rewrite, the only
"feature" of the current code is that the basic algorithm hasn't changed
for a long time now, otherwise bit rot is rampant.

Note that there is one subtle but very important difference in rpm-4.1:

	rpmtsAddInstall() does not keep a refcount on a header.

That means that rpmlib no longer uses headers for added packages internally,
a Header is used simply as a container, rather than anything more important.

OTOH, if you need non erase/install/upgrade modes for rpm, the rpmcli
interface in lib/rpmcli.h is probably easiest to use.

> and secondly: is there any documentation for theese
> lower-level sections ? (is maximum rpm close enough
> to date for reference ?)

"Maximum RPM" ain't gonna be a whole lot of help for the C API.

There's doxygen generated doco, poorly organized, but as accurate
as I can make it. If it's not accurate, it's a bug.


73 de Jeff

Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []