Bug 790147

Summary: Should deplist list non-package dependencies?
Product: [Retired] Pulp Reporter: Jay Dobies <jason.dobies>
Component: user-experienceAssignee: Todd Sanders <tsanders>
Status: CLOSED NOTABUG QA Contact: Preethi Thomas <pthomas>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: mhrivnak, tsanders
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-27 13:59:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jay Dobies 2012-02-13 18:45:20 UTC
When running a dependency list for gofer [1], it intermixes package dependencies with... not sure how to describe them, command dependencies? For instance, gofer has a requirement on package python-gofer, but also has a requirement on /usr/bin/env.

This makes for an awkward view in the CLI [1]. Maybe I'm misinterpretting what deplist is supposed to do, but I was expecting to only see packages that needed to be installed and whether or not they are available. So instead of "/bin/bash", I'd expect to see something like "bash-4.2.20-1.fc16.x86_64".

I'd suggest the following changes:
* An RFE to be able to strip out non-package dependencies, assuming such a request even makes sense (again, maybe I don't have the correct interpretation of what it's supposed to do).
* Sorting to separate packages from these command listings. This may be doable in response to this bug instead of as an RFE.


[1]

[jdob@pulp1 ~]$ pulp-admin package deplist -n gofer -r pulp-f16
+------------------------------------------+
   Dependencies for package(s) [['gofer']]
+------------------------------------------+

 dependency: python(abi) = 2.7 
   Unsatisfied dependency 

 dependency: /usr/bin/env 
   Unsatisfied dependency 

 dependency: /bin/sh 
   Unsatisfied dependency 

 dependency: /bin/bash 
   Unsatisfied dependency 

 dependency: python-gofer = 0.65 
   provider: python-gofer.noarch 0.65-1.fc16

+------------------------------------------+
  Suggested Packages in Repo [['pulp-f16']]
+------------------------------------------+
python-gofer-0.65-1.fc16.noarch.rpm

Comment 1 Pradeep Kilambi 2012-02-14 14:52:41 UTC
The idea of the deplist call is to see all the requires on the rpm thats being looked up similar to rpm -qR or rpm -qf (for a file dep) and show what deps pulp satisfied. The reason you dint see bash-4.2.20-1.fc16.x86_64 is because the repo doesnt satisfy this. If there was bash rpm in the repo you would see that as a satisfied dependency. I dont recommend removing this as file dependency are part of dependency resolution. 

For example i want to subscribe to a repo with gofer rpm but it doesnt have coreutils which provides /usr/bin/env, then my repo is not closed and will fail as part of repo closure. My recommendation is to move this to NOTABUG

Comment 2 Jay Dobies 2012-02-14 15:01:59 UTC
I get the idea that Pulp won't necessarily provide everything, it's the output that still has me confused, and I suspect that is due to the rpm command itself.

In the example I pasted in the original comment, Pulp isn't providing all of the dependencies there either. It still shows python as a package though. That's what's throwing me off, that some appear as executables and some as packages.

Fundamentally I'm with you that the data is valid; if that's what the call to rpm returns I don't want Pulp to be stripping out anything. I do think there are some things we can do with the UI to clean up the output though. Even as simple as ordering the dependencies before we print them will do a lot: it'll make more sense if python and python-gofer are colocated and it will pull all of the executable dependencies in the same area.

Comment 88 Michael Hrivnak 2013-09-27 13:59:27 UTC
pulp no longer has this feature, so I'm closing the bug.