The Provides: in cloud.spec has not much effect for our case, refer this if you're interested: http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package The review/patch I submitted has no useful effect, so need for testing.
+1 to put force install step in the upgrade section of install.sh 0 for automation, as content from old agent.properties will be still required to be manually moved to the new one and renamed. If there is any way to call some perl python script during post install, that may fix/automate this. Pl. explore and discuss possibility, I'll try to see this tomorrow but I'm not sure if that would work. ________________________________________ From: Edison Su [edison...@citrix.com] Sent: Friday, October 05, 2012 11:49 PM To: cloudstack-dev@incubator.apache.org Subject: RE: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0 > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Friday, October 05, 2012 11:05 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [VOTE] how to upgrade CloudStack from 3.0.x to 4.0 > > On Fri, Oct 5, 2012 at 1:58 PM, Edison Su <edison...@citrix.com> wrote: > > Refer to bug CLOUDSTACK-248, the root cause is : > > we change cloud-agent-scripts to cloud-scripts, and change the > installation path from /usr/lib64/cloud/agent to > /usr/lib64/cloud/common. > > But in the source code, there are some other places still use > /usr/lib64/cloud/agent. For backward compatibility, we link > /usr/lib64/cloud/common to /usr/lib64/cloud/agent during the cloud- > scripts installation. > > It works for a fresh 4.0 installation, but doesn't work for upgrade: > > During the upgrade, cloud-scripts will be installed first, then link > from /usr/lib64/cloud/common to /usr/lib64/cloud/agent will be created. > Then cloud-agent-scripts will be uninstalled automatically, thus > /usr/lib64/cloud/agent will be removed. When mgt server starts, it > complains can't find scripts under /usr/lib64/cloud/agent. > > > > Rohit fixes this issue by manually force upgrade cloud-scripts after > the upgrade process, which will install /usr/lib64/cloud/common and > create the link between /usr/lib64/cloud/common and > /usr/lib64/cloud/agent. > > > > Actually we can put this extra installation process into ./install.sh, > so it will become transparent for end users. > > Will it be reasonable/acceptable for the community? > > > > Does using Provides: cloud-agent-scripts in the scripts sections of > the spec file mean that this would be upgraded rather than install > then remove that currently happens? If " Provides: cloud-agent-scripts " just upgrade, not remove, then we don't need the extra manually process any more. Testing the latest build with Rohit's patch.