asterisk: cyclic-deps, gtk, docs

[Mark Purcell]

On Thursday 17 August 2006 17:45, Tzafrir Cohen wrote:
> I was looking at some of the recent changes:

Thanks for the feedback..

> 1. There is a cyclic dependency between asterisk and
> asterisk-{classic,bristuff}. Even if you remove the decepdency of
> asterisk on those two, this means that the init.d and such cannot reside
> in the asterisk package (when you install asterisk you can't be sure you
> have a functional asterisk installed).

But we need to ensure we are in sync now.  asterisk and 
asterisk-classic/bristuff need to be at the same version, as does 
asterisk-config.  Init.d will fail if the asterisk daemon isn't present.

But the default install doesn't start asterisk on load, until default/asterisk 
is modified anyway..

> Furthermore, it means that 'apt-get install asterisk' will not do the
> right thing. Not to mention an upgrade of an old asterisk installation.
> Or if we ever get rid of asterisk-bristuff: people will have to
> expleicitly ask for asterisk again.

apt-get has to move everything together now..  Which is kinda what we want.

> 2. The examples were not originally in the docs package because the docs
> package is a huge pile of developers docs. It includes 78MB, once
> installed. A non-programmer will only need the examples. The sample
> configs are currently a must for anybody configuring an asterisk server
> as they are the de-facto documentation of the config files.

Good call.  I'll put the examples back into the asterisk package...

> 3. The build requirement for asterisk was removed. However how do we
> guarantee that the gtk module is not built accidentally? BuildConfilict
> on the gtk lib, or an explicit rm of the generated module?

I don't think it is an issue, if it gets built accidentally.  Certainly the 
buildd's shouldn't so the archive should be ok, it is rather someones home 
brewed asterisk that might have that problem.  But then it shouldn't be 
critical for them either.

We need to upload something soon, we have too many RC bug reports, which can 
be cleared..

I propose to leave 1 revert 2 and leave 3.

Mark