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
rpm-4.0. (there's no difference right now) has changed the package ordering
Since rpm-3.0.5, the value of %_optflags is saved in package headers, and hence
database. So, if you put -DFOO in %_optflags, you might be able to query the
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 ***