There are several rather easy enhancements for rpmbuild that
might be generally useful.

The first is running rpmlint on freshly built binary packages.
rpmlint does a very good job at detecting packaging flaws
these days.

OTOH, like all lints, one has to be ready for extraneous noise,  
particularly
with a "generic" packaging policy template configuring rpmlint. The  
harder
issue with rpmlint is encapsulating the packaging policy for a build  
destined
for a given distro

The second enhancement is to check freshly built packages against
an "everything" (or custom) rpmdb, looking for unsatisfied dependencies.

The code to do the check is no different than what is done with, say,
     rpm -V --nofiles somepkg*.rpm
In fact, exactly that command could be scripted with --dbpath, and  
executed
after a successful build.

The harder issue with checking for installibility is maintaining the  
database
that is used to check for unsatisfied dependencies in sync with  
(possibly)
rolling release builds. One solution would be to automate the install of
a freshly built package if/when successful.

There are still issues (solvable imho) with a build system that may  
build older/newer
packages that are not candidates for installing into the rpmdb that  
is used to check for
installibility. Adding a marker to freshly built packages that  
determines
whether a successful build should be automatically installed with -- 
justdb
is one possible solution, another would be an external policy that,  
say, always saves
the "newest" EVR.

A third enhancement is already being used by CentOS (and likely other  
build systems),
checking the freshly built package metadata against a known reference.

None of the above are very new or surprising ideas. The main value in  
adding to
rpmbuild, rather than some build system wrapper, is so that packages  
built outside
a build system can achieve the same automagic QA provided by the  
build system itself.

Opinions? Any/all of the above could be added to rpmbuild rather easily.

73 de Jeff