Mitko Haralanov <mitko@xxxxxxxxxx> wrote:
On Wed, 2 Dec 2009 09:11:56 -0800
Andy Helten <andy.helten@xxxxxxxxxxxx> wrote:
The problem I am having is that dependency checking fails during
verification for the shared libraries provided by my RPM unless a
previous version of my RPM is already installed. I would prefer to
leave dependency checking enabled and do not want to maintain the
dependencies on my own. The question is: how do I force RPM
verification to recognize the shared libraries provided by that RPM so
that is doesn't (incorrectly) complain about unsatisfied dependencies.
Note that this failed dependency check does not prevent installation, it
just causes "rpm --verify --package blah-1.7.8.9-1.i386.rpm" to fail.
I believe that what's happening here is that RPM is automatically
generating dependencies by examining the content of your RPM. It
notices that it contains shared objects (which fills in the "Provides")
and it notices that it contains executables linked against shared
objects (which fills in the "Requires").
--verify works on look at your package and comparing it against the
metadata in the database. Since your database does not have anything
that satisfies the requirements of your package, it complains.
If you want to check whether your package will install correctly before
installing use '--test' rather then '--verify'
On a separate note, if you don't want to have RPM automatically
generate dependencies, use the 'AutoReq: 0' field in your spec file.
You can still specify dependencies using the 'Requires' and 'Provides'
fields, which RPM will consider.
Hope this helps.
Yes, this did help. Thank you. I had only just discovered the '--test'
option and started thinking maybe it was more appropriate. But I also
discovered that '--test' only performs MD5 verification over the RPM
header. That is, it does not perform MD5 verification over the packaged
files but, then, neither does '--verify'. Apparently only '--checksig'
does that. This means an install that passes '--test' could fail to
install due to file corruption outside of the RPM header.
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
