Not really a bug (at least not serious) but undesired behavior. Let's say package foo.rpm depends on bar.rpm rpm -i foo.rpm bar.rpm will fail (failed dependencies: bar.rpm is required by foo.rpm), while rpm -i bar.rpm foo.rpm will work perfectly. In given case it's not much trouble, but if you grab some package that depends on several other packages you don't have installed (let's say you want to start SQL database) and then you download all the packages you need, real puzzle starts - instead of just issuing rpm -i *.rpm you have to guess which package install first, which later... or use --nodeps risking missing some important dependency. ps. Will ever programs built and installed from installed source RPMs (so the user could modify compile-time parameters) be added to the RPM database? Sometimes I need to compile some program because i need some non-standard config (i.e. -e and -t in netcat.), and then have to use --nodeps to install programs depending on it since it's not present in the database.
rpm-4.0.[12] (there's no difference right now) has changed the package ordering algorithm. Since rpm-3.0.5, the value of %_optflags is saved in package headers, and hence in the database. So, if you put -DFOO in %_optflags, you might be able to query the installed package to see how it was compiled. Wotta hack ... The Right Thing To Do is add support for user definable tags, but that won't happen for another 6 months or so.
*** This bug has been marked as a duplicate of 12327 ***