There is a dependency problem with 5.211.65-6 update

They more or less speak for themselves:

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

For what it’s worth:

# rpm -qa | grep 'dahdi-linux\|wanpipe\|libtonezone'
libtonezone-devel-2.10.0.1-1.shmz65.1.17.i686
dahdi-linux-debuginfo-2.10.0.1-1.shmz65.1.16.i686
dahdi-linux-kmod-debuginfo-2.10.0.1-24_centos6.2.6.32_431.el6.i686.i686
dahdi-linux-2.10.0.1-1.shmz65.1.16.i686
dahdi-linux-devel-2.10.0.1-1.shmz65.1.16.i686
kmod-dahdi-linux-2.10.0.1-24_centos6.2.6.32_431.el6.i686.i686
wanpipe-7.0.10-1kernel.2.6.32.431.el6.dahdi.2.10.0.1.rel.1.shmz65.1.34.i686
libtonezone-2.10.0.1-1.shmz65.1.17.i686

and

# yum list | grep 'dahdi-linux\|wanpipe\|libtonezone'
dahdi-linux.i686                         2.10.0.1-1.shmz65.1.16        @pbx
dahdi-linux-debuginfo.i686               2.10.0.1-1.shmz65.1.16        @pbx
dahdi-linux-devel.i686                   2.10.0.1-1.shmz65.1.16        @pbx
dahdi-linux-kmod-debuginfo.i686          2.10.0.1-24_centos6.2.6.32_431.el6.i686
kmod-dahdi-linux.i686                    2.10.0.1-24_centos6.2.6.32_431.el6.i686
libtonezone.i686                         2.10.0.1-1.shmz65.1.17        @pbx
libtonezone-devel.i686                   2.10.0.1-1.shmz65.1.17        @pbx
wanpipe.i686                             7.0.10-1kernel.2.6.32.431.el6.dahdi.2.10.0.1.rel.1.shmz65.1.34
dahdi-linux.i386                         2.9.0.1-33_centos6            pbx
dahdi-linux-debuginfo.i386               2.9.0.1-33_centos6            pbx
dahdi-linux-devel.i386                   2.9.0.1-33_centos6            pbx
libtonezone.i386                         2.9.0.1-34_centos6            pbx
libtonezone-devel.i386                   2.9.0.1-34_centos6            pbx

its fine just run through all the upgrades to latest and it works itself out.

Ok, just checking.

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.

Hi, interesting point this one.

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).

Isn’t so?

I don’t think it’s so.

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:

  1. 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.

  2. 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.

As I stated we assume once you start a upgrade you take it to the latest in the track. Its just how it works.

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?

Wow nice tone you are taking. Enjoy the product and the free scripts. Nobody makes you use them. Feel free to just yum update things yourself.

1 Like

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).

Just my 2 cents.