Bug 117386 - ccm upgrade command does not enforce application version dependnacies
Summary: ccm upgrade command does not enforce application version dependnacies
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: installation
Version: nightly
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-03-03 15:21 UTC by Daniel Berrangé
Modified: 2007-04-18 17:03 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-02 17:35:14 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2004-03-03 15:21:44 UTC
Description of problem:
Consider the 'portal' and 'navigation' applications. Version 1.0 of
navigation has a dependancy on version 1.0 of portal. Now the next
release of navigation (1.1) comes along & has a dependancy on version
2.0 of portal. When you run 'ccm upgrade ccm-navigation', however, it
does nothing to check that you've

a) Installed the 1.1 version of navigation
b) Run the upgrade scripts for this version

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


How reproducible:


Steps to Reproduce:
1. Install RPMS portal 1.0 & navigation 1.0
2. Load the applications with ccm load
3. Upgrade the RPM for portal to 2.0 and navigation to 1.1
4. Run the upgrade for 'navigation'

Actual results:
Errors because portal has not yet been upgrade 

Expected results:
If the command is 

  ccm upgrade navigation

then a error message should be printed & no action taken

if the command is

  ccm upgrade portal navigation

then they should be upgraded in dependancy sorted order.


Additional info:

Comment 1 Justin Ross 2004-03-03 18:32:16 UTC
This one requires installed-package metadata that we don't have
(though we've discussed adding it to support the smarter "ccm upgrade
navigation".  And since adding that metadata requires[1] refactoring
loading and initialization, we should do it after the upcoming release.

[1] "requires" is a little strong here.  It could be tacked on to the
existing infrastructure and so avoid refactoring initialization and
require only simpler to changes to loading, but this would have to be
de-tacked-on afterward, so I think it's a bad idea.

Comment 2 Daniel Berrangé 2006-09-02 17:35:14 UTC
Closing old tickets



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