On May 8, 2010, at 9:05 PM, юрка олейников wrote:
> i've tried to da as you told, but have some problem.
> i've added all RPMs from CentOS installation dvd DVD to transaction set (with 'i' parameter) and ts.check() succeeds.
> however the same operation on RHEL RPMs fails on ts.check() and a get a huge list of rpm deps...
Please supply rpm version involved. I can't track with identifiers like
"CentOS" and "RHEL" and DVD.
Be careful with 'i' vs 'u' passed whaten adding elements.
I'd suggest ignoring 'i' and always doing 'u' because rpmlib behavior
is quite different between the two.
Note also that
'i' == -i,--install
'u' == -U,--upgrade
on the rpm CLI, which may help you narrow down to a specific reproducer,
with deterministic behavior. The rpm-python bindings are quite ancient,
with subtly different behaviors amongst different versions.
There's fewer changes on the rpm CLI.
There's also means to more specific debugging (that I can translate)
if you do rpm.setVerbosity() (I think that's the method, I don't use rpm-python daily) twice.
Call rpm.setVerbosity() twice turns on the equivalent of -vv on the rpm CLI.
RPM is quite heavily insturmented, will supply details on almost every operation performed,
but one does need to turn on the diagnostics somehow.
73 de Jeff
> 2010/5/8 Jeff Johnson <email@example.com>
> On May 8, 2010, at 10:26 AM, Jeff Johnson wrote:
> > On May 8, 2010, at 9:15 AM, юрка олейников wrote:
> >> how do i check in python if rpmA has satisfied dependecies from rpmB if i do not want to use rpmdb?
> > If you don't want to use an rpmdb, then you cannot check "added"
> > dependency assertions against "installed" packages. An rpmdb
> > is in fact where the "installed" package metadata lives.
> The specific answer to your question (assuming you don't
> care whatsoever about "installed" package dependencies) is
> 1) Get a transaction
> 2) (counter intuitively) close the rpmdb using the ts.closedb() method.
> 3) add headers to the transaction as if you were going to install.
> 4) call the ts.check() method, and retrieve the dependency failures.
> What I believe you are going to find is that there are many
> failed "installed" dependency assertions that are normally satisfied
> by information contained in an rpmdb.
> To fix _THAT_ problem, just don't do step 2) let the transaction
> access an rpmdb as needed.
> 73 de Jeff______________________________________________________________________
> RPM Package Manager http://rpm5.org
> User Communication List firstname.lastname@example.org
> Be Secure, Stay Open - live w/ OpenBSD
Received on Sun May 9 03:35:55 2010