On Wed, 21 Apr 2004, Steven P. Ulrick wrote: > Hello Everyone :) > I must admit that I only suspect that this is RPM related, but I'm not > 100% sure. I'll begin with a summary about why I only think it might be > an RPM issue: the RPM in question appears to build fine, but the error > quoted in the subject line of this email comes up only when installing > it. > > Anyway, here's the problem in detail: > I make Fedora Core RPM's for Krename, which of course is a KDE/QT based > application. This is such a mystery to me that I think I will describe > the problem in the format of two numbered lists, the first being "Usual > Behavior", the second being "Undesired Behavior" > > "Usual Behavior:" > 1. I Download the tarball of the new version of Krename, and make minor > changes to the spec file, re-archive it, and run "rpmbuild -ta > krename-2.*.*,tar.bz2" on it. > 2. I upload the finished RPM to our churches web server, download it, > and then attempt to install it, usually with "rpm -Fvh krename-(current > version)" > 3. The result of the above steps, until my last two RPM's, has been > perfect success. > > "Undesired Behavior:" > 1. Re-read steps 1 and 2 above to see what the first two steps are to > get the undesired behavior. > 2. Just like above, the RPM finishes building apparently without error. > Problem is, when I attempt to install it, with the same command that I > always use, I get the error that I quote in the subject line of this > email. > > What makes this really strange is that if I compile and install, let's > say for example's sake, krename 2.9.4 from the source tarball, it > compiles, installs and runs perfectly, with full functionality and > performance. Not only that, but if I copy "CONTENTS.cpio" from the > krename 2.9.4 RPM that I just got done telling you causes the error that > is quoted in the subject line of this email, it runs perfectly. > Hi Steve, First off this behaviour is not suprising, and probably rpm is working as designed. When rpm builds a package it actually attempts to figure out for you what libraries your executables depend on. This is a good thing, as it would be quite tedious and ultimately error prone to by hand input all the shared libraries that the executables in your package depend on. That said by doing this, you ultimately end up with automatically generated library dependencies that closely match your build system (by default), and if your build system does not match the system you deploy on, then you get dependcy problems. There are various ways to deal with/manage this, but if all your doing is building one package for a few systems the best thing to do is make your build system look simular to the systems you deploy on. Other strategies involve building chroot's, and some simply turn off automatic dependency checking (see www.rpm.org for info on this; I tend to stay so far away from this practice, that I tend to forget the exact macro, but its simple to do). Another approach though may simply be to insall with --nodeps if you know on the few systems you put this on, that deps are actually provided. Cheers...james _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
