rpm 4.1: Failed Dependencies

[R P Herrold <herrold owlriver com>]

On Wed, 11 Sep 2002, Steven P. Ulrick wrote:

> I just rebuilt rpm-4.1-1.01.7x.src.rpm on Red Hat 7.3, and 
> it provided me with the following packages:
> popt-1.7-1.01.7x.i386.rpm
> rpm-4.1-1.01.7x.i386.rpm
> rpm-build-4.1-1.01.7x.i386.rpm
> rpm-devel-4.1-1.01.7x.i386.rpm
> rpm-python-4.1-1.01.7x.i386.rpm

> I then proceeded to install them using rpm -Fvh *.rpm (the above 5 rpm's
> were the only ones in the folder) and this is the error I received:
> error: failed dependencies:
> 	librpm-4.0.4.so   is needed by kdeadmin-3.0.0-4
> 	librpm-4.0.4.so   is needed by gnorpm-0.96-14
> 	librpm-4.0.4.so   is needed by rpm2html-1.7-6
> 	librpm-4.0.4.so   is needed by rpmfind-1.7-7
> 	librpm-4.0.4.so   is needed by ucd-snmp-4.2.5-7.73.0
> 	librpm-4.0.4.so   is needed by ucd-snmp-utils-4.2.5-7.73.0
  <snip -- duplicates removed>
> I realize that the programs in question require the old (my current)
> version of RPM.
>
> Any help you can provide will be greatly appreciated :)  I'm 
> pretty new at this, but I am willing to learn :)  My brother 
> Dave, who get's paid to work with computers and is our 
> family's Linux guru, thinks I'm a genius (I think he takes 
> my abilities too far :))

Congratulations on joining the *nix tool-builder culture as a 
neophyte builder.  It is _so_ nice to have the freedoms 
of GPL'd Open Source.  Soon you'll be teaching 'Dave' 
some new tools <smile>.

To your question.  Decide if you ever _use_ the packages in
question.  If not, remove each conflicting item permanently.  
This is both good security practice, and makes your system
simpler to maintain in the future.

If your DO use them, retrieve the source RPMs (I suspect you 
might not use the ucd-snmp series -- it changed names at RH 
7.3 as I recall, and if you used it, you'd have probably 
updated it) -- and keep them handy.  Both the production SRPMs 
are available from Red Hat for each of those packages, and the 
'latest' bleeding edge code from the Raw Hide developmental 
FTP archive

Then remove the conflicting packages temporarily, take a
backup tarball of /var/lib/rpm/ as insurance for recovery if
there is a problem, upgrade the RPM transaction set, run:
	 rpm --rebuilddb 
for good measure, and rebuild the SRPMs under the new RPM, and
reinstall.  The RPM API change is significant enough that this
is probably the most direct approach.

Note that there may be build dependencies in that process as
well -- Most carefule builders build as non-root and do so on
a separate developmental chassis, to allow them to solve those
issues in a fashion which does not their impair day-to-day
operation until they are ready to apply a set of updates. See:
   http://www.rpm.org/hintskinks/buildtree/

[Aside:  Is anyone on the list running one of the userspace
Linux virtual hosts inside their day-to-day workstation to
avoid the need for a second chassis?-- I would love to see a
write-up or that, or of cross-arch building, cross this list.]

-- Russ Herrold