Raymond Dans wrote: > A lot has been done recently to get upgrades from 3.10.x to 3.11.y to > work properly. > Part of this work was to add the capability in sipXsupervisor (on > startup) to determine the status of processes in 3.10.x (by examining > and extracting it from the old process.xml files), setting the > appropriate status of these processes in 3.11.y (under the new > process-state directory) and then deleting the old process.xml files. > The problem with this strategy is that when the various components in > sipXecs are updated (using yum), the old process.xml files are > automatically removed by rpm (red hat package manager) since they not > present in the new rpm package.
I am pretty sure that %pre and %post sections of the new (3.11) RPM spec are executed before the old RPM (3.10) is being removed. (http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html) Maybe the proper fix would be to move code that looks for old process descriptors to that section? > I'd like to propose the following changes to resolve this issue: > > 1. In each of the appropriate rpm package spec files add a "post" > activity that checks for the existance of the old process.xml file (in > /etc/sipxpbx/process.d) and if it exists, copy it to the new process xml > file location (i.e. /usr/share/sipxecs/process.d). This will not cause > a conflict because the new process xml files have a slightly different > naming convention (i.e. <process name>-process.xml instead of <process > name>.process.xml). > > 2. Modify the special upgrade code to now look in > /usr/share/sipxecs/process.d for the old process definition files and > then remove them from that location after the process status is > determined and written. > > > Does this type of change make sense or is there an even easier way such > that the package manager won't remove the old process xml file during > its cleanup process after the software upgrade? D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
