RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 748054 - RFE: Support installonlypkgs functionality for rhev-hypervisor packages
Summary: RFE: Support installonlypkgs functionality for rhev-hypervisor packages
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On:
Blocks: 748055 863579
TreeView+ depends on / blocked
 
Reported: 2011-10-21 20:16 UTC by Mike Burns
Modified: 2016-04-26 16:24 UTC (History)
10 users (show)

Fixed In Version: yum-3.2.29-31.el6
Doc Type: Enhancement
Doc Text:
Clone Of:
: 748055 863579 (view as bug list)
Environment:
Last Closed: 2013-02-21 10:12:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0406 0 normal SHIPPED_LIVE yum bug fix and enhancement update 2013-02-20 20:50:44 UTC

Description Mike Burns 2011-10-21 20:16:27 UTC 
Description of problem:
There are packages that would benefit from being able to have multiple versions installed concurrently, but there is no easy way to do this.  Currently, the only process is to manually change the config.py file or to edit the yum.conf file directly and manually.  In either case, you need to know something about how installonlypkgs works in order to do this.  

If you edit yum.conf, you need to make sure you add the appropriate kernel package(s) to the entry or you risk breaking the machine with the next kernel update.

The ideal solution is for a package that can be installed concurrently to dynamically on installation change the configuration to allow multiple installs.

It would also be useful if the package could set a unique limit on the number of instances to keep rather than a single global entry for all packages in the installonlypkgs list

Version-Release number of selected component (if applicable):
yum-3.2.29-17.el6 (6.1)

How reproducible:
always

Steps to Reproduce:
1. 
2.
3.
  
Actual results:
Need to manually edit yum.conf correctly or hack source correctly

Expected results:
Some method for a package to dynamically add itself to the installonlypkgs list


Additional info:

The basis for this is the rhev-hypervisor package.  It lays down only an iso file (that is versioned) and there is a strong use case for side by side installs.  

The rhev-hypervisor package is being renamed such that rhel 6 versions will be rhev-hypervisor6 and rhel 5 versions are rhev-hypervisor5.  This will continue to going forward with rhel 7, rhel 8, etc, so adding the package in the config.py file would be a temporary fix.
Comment 1 James Antill 2012-02-14 20:44:10 UTC 
 I've posted a patch upstream, for review, which adds:

installonlypkg(kernel-module)
installonlypkg(vm)

...to the list, so any package providing either of those will get installonly functionality.
Comment 2 RHEL Program Management 2012-05-03 05:08:50 UTC 
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 3 RHEL Program Management 2012-07-10 07:39:19 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 4 RHEL Program Management 2012-07-11 02:11:13 UTC 
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 5 Karel Srot 2012-07-30 15:36:50 UTC 
Hi James,
am I right that the "dynamic installonly configuration" wasn't implemented, just the installonly package list has been extended?
Comment 6 James Antill 2012-08-23 19:33:14 UTC 
 Depends on your definition of "dynamic", I guess, adding one of the new generic provides to your package will make your package follow the installonly process.
Comment 7 Karel Srot 2012-08-24 05:56:11 UTC 
(In reply to comment #6)
>  Depends on your definition of "dynamic", I guess, adding one of the new
> generic provides to your package will make your package follow the
> installonly process.

Well, that is why I was asking. I do not think that "kernel-module" nor "vm" sounds __generic__. It sounds like something related to kernel-module or virtualization. Obviously something that fits RHEV but nothing I would like to add for a (not kernel/virtualization related) package that needs to be installonly (from whatever reason). I would rather expect something like "install-only-pkg" provides.
Comment 8 Jan Zeleny 2012-09-07 13:12:12 UTC 
I tend to agree with Karel here. How about adding another item to the list, this time really generic, something like

installonlypkg(install-only)

would that be acceptable for you James?
Comment 9 James Antill 2012-09-10 13:45:57 UTC 
 While we could add a installonlypkg(generic) or whatever, making a package installonly is proposed as a solution to a problem much more often than it is a solution to a problem. Also with the categories we could look at the packages and extend the functionality, like we do with the kernel itself (Eg. don't remove running version etc.).
Comment 10 Jan Zeleny 2012-09-10 14:47:06 UTC 
Sounds reasonable. However if we want to go this way, it is important to state in this BZ that the fix is not generic. It is in fact quite specific only for handful of packages and every component/package that wants to utilize install-only functionality should file new BZ for evaluation and inclusion in the yum code. Everyone in agreement?
Comment 11 Jan Zeleny 2012-09-11 08:34:46 UTC 
I changed the summary as outlined before. Karel, are you ok with this fix given that the target package group has been narrowed down significantly?
Comment 18 errata-xmlrpc 2013-02-21 10:12:28 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0406.html
Note You need to log in before you can comment on or make changes to this bug.