This is supposed to address:
| insserv: Service mysql has to be enabled to start service kamailio-proxy
| insserv: exiting now!
| update-rc.d: error: insserv rejected the script header
| dpkg: error processing kamailio (--configure):
| subprocess installed post-installation script returned error exit status 1
Let's find out whether my approach works for CE + PRO as well,
might be a no-brainer with our custom ngcp stack so let's see
what we explore in release-trunk.
From: Michael Prokop <mprokop@sipwise.com>
This solves the mysql dependency not being
matched in pro systems because mysql is not
present in rc.d links. Kamailio should not run in
inactive nodes too. So we make sure that kamailio
will never be started by postinst scripts except
in active nodes.
The change from svn r10685 is incomplete, causing the upgrade to fail:
| Unpacking replacement kamailio ...
| dpkg: error processing /var/cache/apt/archives/kamailio_3.3+ngcp2.6.3_amd64.deb (--unpack):
| trying to overwrite '/etc/init.d/kamailio-proxy', which is also in package ngcp-system-tools-ce 0.4.5
Needs review, testing + release (branch/tag + release-2.6-update) by Jon.
From: Michael Prokop <mprokop@sipwise.com>
If the scripts exist during clean install, the
postinst script will take care of adding
kamailio-proxy and kamailio-lb rc2.d links. By
default no run is set to these scripts so we
make sure that we'll only run the templates ones.
We'll use a very recent version of kamailio in
2.6. It's better to have a dbg package that can
be installed in our test systems to debug any
problem we find.
Should we install it also in customer servers?
From 3.3 upstream:
rr(k): fixed offset in building new route header
- related to the previous fix done to strict routing intermediary hop
(cherry picked from commit e154b2fb9f02d56d9c6a4b2d285791151ae0c8a3)
Keep 3.3 as kamailio version, not 3.3.1 as we
might update to other 3.3 releases within the
same ngcp version.
Set Sipwise version to ngcp2.6.0 for branching per ngcp release.
It does not contain ./pkg folder yet.
If a patch is sent upstream we can remove afterwards.
It makes also easier to sync with upstream and
just apply the list of patches.
Con: Each change to kamailio code will need to be
stored as patch too. Do you read me Richard and Andi? :)