Hide Forgot
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.
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.
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.
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.
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.
Hi James, am I right that the "dynamic installonly configuration" wasn't implemented, just the installonly package list has been extended?
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.
(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.
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?
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.).
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?
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?
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