[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)



Is this good practice to loop through the
installed packages in the db ?

===========================================================================
    if (rpmdbOpen ("/", &db, O_RDONLY, 0) == 0) {
        if ((iter = rpmdbInitIterator(db, RPMDBI_PACKAGES,
				  NULL, 0)) != NULL) {
	    while (h = rpmdbNextIterator(iter)) {
	 	// get desired info on installed package ...
		headerGetEntry(...h...);
	    }
	    iter = rpmdbFreeIterator(iter);
	}
	if (rpmdbClose(db)) {
	    /* I have big problems ? */
	}
    }
===========================================================================

Regards,
			-Tristan



Jeff Johnson wrote:
> 
> 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,
> specifically/skeletally
>         ts = rpmtsCreate();
>         fd = Fopen(...)
>         rpmReadPackageFile(..., &h, ...)
>         rpmtsAddInstallElement(..., h, ...)
>         Fclose(fd)
> 
>         rpmtsCheck(ts, ...)
>         rpmtsOrder(ts)
>         rpmtsRun(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.
> 
> HTH
> 
> 73 de Jeff
> 
> --
> Jeff Johnson    ARS N3NPQ
> jbj@redhat.com (jbj@jbj.org)
> Chapel Hill, NC
> 
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/rpm-list





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