Bug 701529

Summary: RFE: Support virtual "provides", in packages listed in activation keys
Product: Red Hat Satellite 5 Reporter: Tim Jackson <tjackson>
Component: ProvisioningAssignee: Tomas Lestach <tlestach>
Status: CLOSED DEFERRED QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: djuran
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-05 14:22:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 260381    

Description Tim Jackson 2011-05-03 05:46:08 UTC
Description of problem:
RPMs typically have a long list of Provides, some automatically generated and some manual. In some cases it is preferable to use these rather than the package name itself in a dependency, for various reasons (e.g. "libfoo.so.X" rather than a package which happens to include libfoo.so.X, or "php-[modulename]" which may be a package in itself or provided by another package.
One can easily use virtual provides via "yum" or RPM dependencies. 
It would be very useful to be able to use this familiar functionality within Satellite activation key package lists, i.e. being able not just to list physical packages but things that might be listed in a Provide.

Version-Release number of selected component (if applicable):
Satellite 5.4

How reproducible:
Always

Steps to Reproduce:
1. Create an activation key
2. In the list of packages to be installed by said activation key, list something which is a virtual provide from another package. e.g. "mod_php" (which is provided by the physical package "php")
3. Activate a machine using said activation key
  
Actual results:
Nothing is installed to satisfy the desired function. ("php" is not installed in this case)

Expected results:
A package providing the required function is installed ("php" in tis case)

Additional info:
This would also function as an alternate solution to bug #701266, as "/usr/lib/libfoo.so.X" could be listed instead of a package name with a specific i386/i686 arch suffix.