> I'm trying to figure out how RPM determines what files are > provided by a package. Your real problem is actually knowing how rpm determines what is /needed/ by a particular package. But the answer to both is scripts in /usr/lib/rpm. And if you need to, you can overrided these with your own scripts, but that's another story. > I'm in a position where I need to > upgrade a particular package that provides a couple of > shared libraries. The new version provides newer versions > of the libraries, and I want to add a couple of symlinks > in the package that will act as the old versions of the libraries for > backwards compatibility with all my other existing packages. > Unfortunately, when I try to install the package, RPM spits out a huge > list of dependencies that will be broken, and I can't figure > out how to get the package to say that it actually does provide > the libraries in question. In theory at least rpm dependencies are not file-based. Hey, the documentation says so, it must be so :-) But when rpm itself is allowed to calculate dependencies at package build time, you may end up with things that look like pathnames to files, and also to versions of libraries where you didn't need it to be that tied to a specific version. As far as I know, this is because rpm can't figure out what else do do in these cases. If you don't like this, then you can give rpm more precise information in the spec file about what the requirements are, and then it won't outguess you. At the same time, you can also instruct rpm what a particular package provides, so if the requirements of other packages can be handled that way, it's not hard to take care of. The two specfile directives that are interesting here are Requires and Provides. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
