Bug 790147 - Should deplist list non-package dependencies?
Summary: Should deplist list non-package dependencies?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Pulp
Classification: Retired
Component: user-experience
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Todd Sanders
QA Contact: Preethi Thomas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-13 18:45 UTC by Jay Dobies
Modified: 2013-09-27 13:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-27 13:59:27 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.