freepbx 2.2.0 available on the svn

[Chris Halls]

On Sun, Feb 04, 2007 at 06:36:46PM +0200, Diego Iastrubni wrote:
> First of all, thanks for the attention. I would really like to hear about 
> installations, and specially about bad experience

Glad to help :) I'll keep you posted.

> On Thursday 01 February 2007 17:52, Chris Halls wrote:
> > The mysql problems that I reported previously did not show up again. So
> > maybe it was a problem because I was testing previously on a sarge machine,
> > and on the new machine I am using etch/unstable.
> see changeset 3104 :)

Oh, cool. Thanks!

> > - I think that freepbx-common would be a better name than freepbx-admin:

> or as you described in a later email: freepbx-core. Not sure, but I think core 
> will sound better.

Agreed.

> The issue is that is contains much more then the core 
> module, but I do not want to split the package even more. It's a mess 
> already.

Right. I don't think that's a problem: core is a pretty generic name
anyway.

> > So if you did
> >  apt-get install freepbx-common
> > you would get freepbx + sqlite + apache2 + php5. You could change that by
> > adding packages for the option you wanted, e.g. apt-get install
> > freepbx-mysql freepbx-mathopd.
> Now, if I understand what you say correctly, this means moving all my code of 
> the freepbx-admin.postinst into the new packages post.inst. While it is a 
> VERY GOOD solution, I am still afraid of code duplication: as all those 
> packages will contain about 70% of the same code. 
> 
> Since the mess available in the postinst of those package is unacceptable, I 
> will have to go your way in the future. To overcome the problem of "someone 
> fixing freepbx-apache1-phpcgi5-mysql4 I will had commens to each of those 
> files, in hope that he who commits will remember to commit in the other 
> flavors.

Looking at the existing postinst I don't see a lot of duplication - most
stuff is pretty specific to one type of backend/webserver. But there is
no problem either with code duplication: You have 2 options:

1. Add a file to the -core package that contains the common code, and
call it from the postinst

2. At package build time, dynamically create the freepbx-*.postinst by
patching it into the postinsts. X used to do this.

So youi can do things like:
----- freepbx-weblib -----
update_webserver()
{
  user=$1
  webserver=$2

  if groups $user | grep -q -w -v asterisk ; then
    adduser $user asterisk

    if [ -n "$webserver" ]; then
      echo "Restarting $webserver to take usage of the new ownership"
      [ -x /etc/init.d/$webserver ] && invoke-rc.d restart $webserver || true
    fi
  else
      [ -x /etc/init.d/$webserver ] && invoke-rc.d reload $webserver || true
  fi 
}
--------------------------

-----freepbx-apache2.postinst.in ----
case "$1" in
  configure)
    update_webserver www-data apache2
    ;;
esac
-------------------------------------

------debian/rules fragment ---------
  cat debian/freepbx-weblib > debian/freepbx-apache2.postinst
  cat debian/freepbx-apache2.postinst.in >> debian/freepbx-apache2.postinst
-------------------------------------

I hope that explains what I'm trying to do.

> > - How about adding a link /etc/freepbx.conf -> amportal.conf? It would make
> > it easier for people looking for /etc/<packagename>.conf.
> This should be done upstream. I talked with Rob Thomas about this. This will 
> be part of 2.3, and in the near future our packages as well (even in 2.2).

Cool, that's great you are talking to upstream.

> > - Not completely a freepbx packaging issue: When I tried a fresh out of the
> > box install, asterisk wouldn't start because RUNASTERISK=no
> > in /etc/default/asterisk. It wasn't obvious that this was a problem -
> > XXXXXXXXX

Ooops, the XXXXX was to remind me to research this and write more, sorry.

> See above. Tzafrir is trying to push the "asterisk should be enabled by 
> default" patch for a year or so.

Oh, right. So what's the status on this one?

> Next week. I still need to make the thing stable, and many of the modules are 
> not working on sqlite3 for me (this is a must for our work here). 

I found a problem in the agi scripts which I have fixed with a new patch. I
don't know if it helps you. I also found that there are some hidden defaults in
the php if variables like AMPDBNAME are not set in amportal.conf. I have
added a patch for the perl scripts to use these defaults too.

> I would like someone to test the pgsql support. As far as I can tell, "it 
> should work", but since no one has ever tried it, I am not sure. This could 
> be really cool support sqlite3/mysql/pgsql all in the same time.

Oh cool. Count me in - our company is very big on pgsql and we have several
developers.  Let's add this once the package structure and postinsts are sorted
out. I'm happy to do the testing.

Chris