Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 17377

Summary: depend check in packages in command line.
Product: [Retired] Red Hat Linux Reporter: SharpFang <bw>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 6.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-01-09 15:32:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description SharpFang 2000-09-09 09:57:37 UTC
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.

Comment 1 Jeff Johnson 2001-01-09 15:32:36 UTC
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.

Comment 2 Jeff Johnson 2001-01-09 15:34:20 UTC

*** This bug has been marked as a duplicate of 12327 ***