how to get the return value for rpm installation

We used pkgadd in solaris, currently we want to replace pkgadd w/ rpm on the linux. However we haven't found the return value for rpm in the man page on linux. How could we deal with it? how could we know that whether rpm does successfully or not?
Here is how we called pkgadd in the c code. When we replace pkgadd w/ rpm, we find that retval=0 no matter successfully or not. How to deal w/ it?

---

    133     /* execute pkgadd to install the package
    134     */
    135     sprintf(syscmd, "/usr/sbin/pkgadd -a %s -d %s -R %s %s",
    136                     adminfile,pkgdir,rootdir,pkgname);
    137     /*
    138      * Use WEXITSTATUS to check the actual return value from
    139      * the pkgadd command that is passed to "system".
    140      */
    141     retval = WEXITSTATUS(system(syscmd));
    142     /*
    143      * Exit status 0, 10 and 20 of Sun's pkgadd are all successful
    144      * installation, so we want to treat them as success cases too.
    145      */
    146     if ( retval != 0 && retval != 10 && retval != 20 ) {
    147         fprintf(stderr,"%s: pkgadd failed (retval=%d)\n",argv[0],retval);
    148         exit(-1);
    149     }

---

Rpm does return non-zero exit status when one or more of the specified actions fail, eg

[root@dhcp102 ~]# rpm -Uvh /tmp/baddep-1.0-1.noarch.rpm ; echo $?
error: Failed dependencies:
	iambad >= 5 is needed by baddep-1.0-1.noarch
1

Maybe you're being caught by the fact that recent (rpm >= 4.6.0) considers "failure" somewhat differently than one might expect: scriptlets returning error codes aren't considered hard failures, except in the case of %pre and %preun which actually prevent the package from installing. The criteria for package install/upgrade/erase "success" in rpm is whether the files actually got laid down on disk and header added to the database, failing post scriptlets dont affect that (and its not possible to roll back on such a situation).

The current return code of "return number of failed items, but 254 at most" (with the above criteria for "fail") is rather useless for any purpose at all though, and there have been other requests to provide more meaningful return codes for rpm operations. The problem is encoding meaningful information about a transaction consisting potentially of thousands of packages into a single short integer...