At least with a zip file it is easy to see what is there, not so with an rpm on a standard OS/2 v4.52 install.
Use Arca Noae Package Manager (ANPM). Find the package in the list, highlight it, RMB to get the menu, and click Contents. It will tell you what is in the package, and where it is (or will be placed) in the directory structure.
There is also the WPIVIEW program (at Hobbes), that will show you what is in WarpIn archives.
The biggest "problem" with RPM/YUM, is that it takes some control away from the user, because everything is expected to be where it is supposed to be. If the user simply goes along with what it does, it usually works well. As soon as the user thinks they are smarter, and tries to modify what RPM/YUM does, all H__L breaks loose.
In Linux, they have the ability to use different versions of the same files, while OS/2 (mostly because of the 8.3 file name restriction) can really only use one, although there are packages that do supply older versions of some files, while still using the newer ones. Since Linux is micro managed by package authors, it should never be necessary for a user to even think about what might be in a package. If it doesn't match what you have, it is supposed to download what you need, or tell you that the package does not apply to your system. Of course, that doesn't always work as it should, and it is one of the reasons why most Linux distros have abandoned RPM/YUM in favor of something better.
We have what we have, and it works pretty well, most of the time. Using ANPM makes using RPM/YUM a whole lot easier, than trying to use the command line. Additionally, all new files are supposed to be backward compatible, so that breakage does not occur. Of course, that also has problems. One of the biggest problems is the old EMX package. RPM/YUM will replace some of those files, apparently breaking things that use the old EMX stuff. The problem is solved by removing the old EMX stuff, and install the emxrt package using RPM/YUM (ANPM). I have no idea how a user is supposed to know things like that, but asking in an appropriate place, in an appropriate manner, usually gets answers.
Building a RPM package puts a lot of responsibility on the person who does the packaging. They need to make sure that they don't replace things that shouldn't be replaced, and they need to be sure that everything that is required is installed, where it is supposed to be. Generally, only the program author knows all of the details, so they are really the ones who should be making the package. Trying to do it, as Martin is with a program from another source, can be a bit of a challenge. Another big problem are stray DLLs (and other things), that were previously installed in other ways, can be found, and used, when they shouldn't even exist anywhere on the system. RPM/YUM makes no attempt to delete those things.