Bug 98669
| Summary: | Wanted: Upgrade support | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Toralf <bugzilla> |
| Component: | redhat-config-packages | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | tao |
| 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: | 2005-09-21 17:58:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This isn't going to happen with the current generation of system-config-packages. The next generation tool (which should hopefully be in FC5) will have better support for this. |
Description of problem: redhat-config-packages should support upgrades of packages. Version-Release number of selected component (if applicable): 1.1.8 or 1.1.9 How reproducible: Steps to Reproduce: 1. redhat-config-packages --tree <install tree> 2. Install a package... 3. exit 4. Replace the rpm file for the above mentioned package on <install tree> with a newer version (and run genhdlist etc.) 5. redhat-config-packages --tree <install tree> Actual results: Nothing special... Expected results: "Update" enabled before anything is selected. Pressing the button directly will install the new version of the package. Additional info: What I'm really saying is that it would also be nice to be able to use redhat-config-packages to keep a system up-to-date. Yeah, I know that up2date may be used for that, but I don't think that tool is very practical when you are maintaning a network with several similar setups. Some sort of special behaviour when comps.xml has changed would also be nice, but may be hard to implement; I'm assuming that the package group state as such isn't saved anywhere.