Downloading Packages:
dahdi-linux-2.9.0.1-33_centos6.i386.rpm | 738 kB 00:09
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
dahdi-linux = 2.10.0.1 is needed by (installed) kmod-dahdi-linux-2.10.0.1-24_centos6.2.6.32_431.el6.i686.i686
dahdi-linux = 2.10.0.1 is needed by (installed) wanpipe-7.0.10-1kernel.2.6.32.431.el6.dahdi.2.10.0.1.rel.1.shmz65.1.34.i686
You could try running: rpm -Va --nofiles --nodigest
Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2014-10-15-01-32bKq6ou.yumtx
SCRIPT---FAILED ON STAGE 2--Failed to verify dahdi-linux-2.9.0.1 RPM was installed
and
Downloading Packages:
libtonezone-2.9.0.1-34_centos6.i386.rpm | 11 kB 00:00
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
libtonezone = 2.10.0.1-1.shmz65.1.17 is needed by (installed) libtonezone-devel-2.10.0.1-1.shmz65.1.17.i686
You could try running: rpm -Va --nofiles --nodigest
Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2014-10-15-01-33Jx9Hos.yumtx
SCRIPT---FAILED ON STAGE 2--Failed to verify libtonezone-2.9.0.1 RPM was installed
Moving to Next Step
Checking to see if we need to update kmod-dahdi-linux-2.9.0.1
updating kmod-dahdi-linux-2.9.0.1
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile
Setting up Install Process
Package matching kmod-dahdi-linux-2.9.0.1-72_centos6.2.6.32_431.el6.i686.i686 already installed. Checking for update.
Nothing to do
SCRIPT---FAILED ON STAGE 2--Failed to verify dahdi-linux-2.9.0.1 RPM was installed
Moving to Next Step
Checking to see if we need to update wanpipe-7.0.9.3-kernel.2.6.32.431.el6.dahdi.2.9.0.1
updating wanpipe-7.0.9.3-kernel.2.6.32.431.el6.dahdi.2.9.0.1
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile
Setting up Install Process
Package matching wanpipe-7.0.9.3-kernel.2.6.32.431.el6.dahdi.2.9.0.1.rel.68.i686 already installed. Checking for update.
Nothing to do
SCRIPT---FAILED ON STAGE 2--Failed to verify wanpipe-7.0.9.3-kernel.2.6.32.431.el6.dahdi.2.9.0.1 RPM was installed
It looks like it got ahead of itās self. upgrade-5.211.65-3.sh installed dahdi-linux-2.10.0.1-1.shmz65.1.16.i686ā¦ probably just by getting the latestā¦ then it trips over an attempt to effectively downgrade to dahdi-linux-2.9.0.1-33_centos6.i386.rpm in upgrade-5.211.65-6.sh, which explicitly call out the version, but the downgrade fails because itās already taken on the newer dependencies.
Itās problematic to allow an update from the repo, unconstrained by the version, when the update scripts are incremental and have hard coded version dependencies. It may work fine at the time because of the state of the repo, but eventually falls apart running against the moving target.
Just my thoughts: update scripts (which take care of updating both FreePBX GUI Modules and FreePBX Distro RPM packages), in my opinion, havenāt any āhard coded version dependenciesā (as you wrote) and this explain why, because they manage a series of āyum upgradeā commands (sometime restricted to specific RPM or group of RPMs), they are āvalidā (in the sense of updating from a particular running version to a particular newer version of a RPM package) only when they are released (in that very tight time-frame window).
A part from checking at which version the running FreePBX Distribution actually is (and this could be thought as a way of temporarily ālock downā RPM packages constituting the Distro but itās not), each FreePBX Distro upgrade script is (AFAIK) not bounded to any hard coded version of any RPM packageā¦each upgrade script upgrades some or all RPM packages against the newest available version which is available on each relevant defined repository at time of runā¦so if an RPM package changes after you applied a FreePBX Distro upgrade script then you would re-run it again or (search) and perform manually a āyum upgradeā for that particular RPM packages (if that is advised by Developers) that changed in between.
In other words: if applying the -19 upgrade script upgrades the RPM of package āXā at version ā1ā at time ātā (when developers released the -19) then, if package āXā at time āt+1ā changed in newer version ā2ā (for any reason) in the repository, applying -19 upgrade script after time āt+1ā once again it lets you to have a FreePBX Distro which still is ācalledā -19 but not as the previous ā-19ā (at time of its first upgrade) because now the āXā package is in its ā2ā version. Maybe itās a silly consideration but this means that ā-19ā iteself doesnāt mean nothing about the actual status of the FreePBX Distro (only the whole status of its installed RPM Packages - and FreePBX GUI Modules - is able to provide its true level of update status).
upgrade-5.211.65-3.sh does a yum -y update asterisk1*, so at -3 you get all of the latestā¦ which, if you run it now you get dahdi-linux-2.10.0.1 in addition to itās dependencies.
There is the first issue. If I say I am at distro version 5.211.65-3, that is meaningless. I have to say Iām at distro version 5.211.65-3 + date_I_ran_the_script. That is because the repository isnāt static and three different people could run the update script on three different days and end up with three different versions of Asterisk or Centos components.
Then upgrade-5.211.65-6.sh checks for dahdi-linux-2.9.0.1. So here the problem is compounded. Itās checking for a specific version of a component at step -6 within a lifecycle management scheme that isnāt consistently managing versions. Additionally, itās checking for a specific version - is dahdi-linux-2.9.0.1 == dahdi-linux-INSTALLED - rather than is dahdi-linux-2.9.0.1 > dahdi-linux-INSTALLED. Since dahdi-linux-2.9.0.1 != dahdi-linux-2.10.0.1 it attempts to downgrade dahdi-linux- from 2.10.0.1 to 2.9.0.1, but fails because 2.10.0.1 has dependencies and yum wonāt allow it. Those are the kinds of problems you encounter if you donāt maintain strict version discipline.
So, -1, -2, ā¦ -x are just āstepsā not versions. All systems @ -19 may have completely different groups of component versions depending on what was in the repository at that time.
So, I think this is important for two reasons:
If Iām a support person and Iām trying to support a system I cannot just look at /etc/schmooze/pbx-version, I actually have to go do a rpm -qa in order to see what version is really running on the system. If I come here, open a support topic, say Iām at distro level -xx and Iām getting error yyyyy, twenty people will come along and tell me theyāre at -xx and it works fine for them so it must be me.
If Iām a developer Iām going to be fighting moving targets and developing brittle, error prone, scripts because there is no way on earth Iām going to be able to anticipate valid and invalid conditions that will result from someone running my scripts at different points in the future.
The distro recognizes this aspect. This is why upgrade scripts are incremental. Itās too complex to try and develop an upgrade script that attempts to bring you up-to-date from some arbitrary point in time, because the starting point determines all the steps required and you have no idea what the future holds. In stead, incremental scripts take you from known state -3 to known state -4 and then known state -4 to known state -5. But in this case -3 did not go to a known state, it went to an arbitrary, most_current_as_of_point_in_time state, which then invalidated all future assumptions about known state. This thread exists purely because -6's known state assumptions were invalidated by previous steps.
Iām just trying to lay out the facts, this is not [much] of a judgement. I donāt know if there is a certain design philosophy and this is indicative of that philosophy, or if itās a result of an unintended deviation from the normal practice. Also, while this is way over-thinking the specific case that started this thread, it is germane to the broader topic of version control and configuration management.
Which is exactly what I did - started and finished within 24 hours. But, did you assume I would wait 10 months to even start the first one? Did you account for all of the things that might break or the unintended consequences that would occur because running it 10 monthās in the future would install something completely different than what was there when it was written and tested? If -6 breaks because of -3, how do I get all the way to -19? Youāre not only assuming that I will start with -1 and go all the way to -19, but also assuming that I can. If -3 breaks -6, then -7 through -19 are moot.
Yes, from experience we now know that everything worked out just fine in this specific, known, case, and there is no issue here with that at all (as of this moment in time anyway). The scripts made a lot of concerning ānoiseā, but the end result was a non-issue.
But, it also surfaces a broader issue with version control in general. This is the nature of shared libraries and dependency management. Even if there is no issue in the end, which wonāt always be the case, there is still a cost involved in letting scripts kick out errors as an āacceptableā means of handling a non-error. So, someone has to stop and take the time to question the error case since there is no way to know in advance the difference between acceptable errors and unacceptable errors. And then more people need to take time to answer it. That all adds up $$$. Then there is the intangible cost like the reputation hit you take for āthose guys donāt write clean upgrade scriptsā comments that start flying around. Just sayinā¦
Just my opinion, but -3 should have installed the version of the components that were current at the time of release, so in that way -3 always generates predictable results regardless of how many days have passed since, and, all successors then can start where they should, and not get tripped up by some predecessor that got ahead of itās self and resulted in a fatal error as the result of an unexpected condition. There is significant value in that kind of discipline in terms of product quality, reduced support costs, and reputation. And, Iām talking methodology in general, this case has been adequately beaten to death, Iām more concerned about the case another 10 months from now when I try to do another upgradeā¦ and it completes cleanly?
Thatās exactly what I meant to write as my thought.
Exactlyā¦and, under this light, (probably) the whole āversioning conceptā adopted for FreePBX Distro becomes highly questionable (but, actually, that way is the way it is) if compared to what normally happens on a generic Linux distribution (rolling or not).