asterisk: cyclic-deps, gtk, docs

[Jonas Smedegaard]

On Sat, 19 Aug 2006 21:29:56 +0300 Tzafrir Cohen wrote:

> > > > > until
> > > > > default/asterisk is modified anyway..
> > > 
> > > One way out of it is not to put /etc/default/asterisk in the
> > > package. The way it is now, every upgrade of asterisk updates
> > > that file. That file can have nothing by default. 
> > 
> > That file is (and must be) a conffile. As such, you are incorrect:
> > 
> > The file is only updated if accepted by the local admin. And
> > requests for updates are only done each time the content of the
> > packaged file changes between installed and to-be-installed package.
> 
> This is nice in theory.
> 
> In practice any upgrade of asterisk would be accompanied by an upgrade
> of asterisk-config, which updates tons of config files. Thus you'll
> get asked many times if you want to accept or reject changes. This is
> a pain. Most users will take the "safe" way of not updating, and then
> the update of asterisk-config would be just a waste.

I was talking specifically about /etc/default/asterisk - as was done
before me in this thread, I believe.

Dealing with the big load of config files with no sane defaults, is a
different issue. I have opinions on handling that too, but won't go into
details now (busy with real life stuff).


> > If we want to change the default of the package from not starting
> > the daemon to starting it, then the correct approach is to simply
> > change the packaged file.
> > 
> > That way users updating the package are made aware of the change.
> > 
> > That's the point of conffiles - don't try to defeat that :-)
> 
> I just say that a sane default is an empty file. No point in creating
> extra work for the userwhere none is needed in the first place.

I disagree for the specific case of /etc/default/asterisk - have a look
at other files in that directory for inspiration.

Yes, policy requires us to deal properly with that file missing
completely, or not providing any defaults: We should "pre-load" same
defaults within sysV script itself. But still we should include a
non-empty etc/default/asterisk IMHO.


> > > > Not good enough: removing (but not purging) an earlier asterisk
> > > > leaves a (possibly enabled!) default/asterisk that then may
> > > > cause trouble on install, as you cannot be sure of the order of
> > > > install of packages.
> > > > 
> > > > Package asterisk can then instead predepend on one of the
> > > > packages containing the binary, but predepends should generally
> > > > be avoided.
> > > > 
> > > > 
> > > 
> > > If the package that contains /usr/sbin/asterisk is not at least
> > > unpacked when the package that contains /etc/init.d/asterisk is
> > > configured, asterisk will fail to start.
> > 
> > Correct. That's another uglines of this.
> > 
> > The maintainer of dovecot solved similar issues among the binary
> > packages dovecot-imapd, dovecot-pop3d and dovecot-common.
> > 
> >  * dovecot-common provides sysV script
> > 
> >  * SysV "start" action fails silently if binary does not exist
> > 
> >  * SysV "start" action uses treats already running as no error
> > 
> > 
> > That last one bit me today: Some package other than asterisk itself
> > is updated in same batch as asterisk, restarts the daemon, and when
> > asterisk later attempts to start it again after updating, it fails,
> > telling to use restart instead.
> 
> Could you please be more specific? I don't follow you here.

Debian Policy, section 9.3.2:

> The `init.d' scripts should ensure that they will behave sensibly if
> invoked with `start' when the service is already running, or with
> `stop' when it isn't, and that they don't kill unfortunately-named
> user processes.  The best way to achieve this is usually to use
> `start-stop-daemon'.

Normal setup is to use "start-stop-daemon --oknodo" in start action.


I believe the foolowing is unreliable with current asterisk packaging:

 1) Install package(s)

 2) Customize configuration (read: enable the daemon!)

 3) remove the package(s), leaving the config behind

 4) Install the package(s)

The reason it is unreliable is that if asterisk is configured before
asterisk-bristuff is unpacked, there's no daemon to start.


With dovecot, dovecot-common tries to start, but dovecot-imapd and
dovecot-pop3d also invokes the dovecot start action, with the above
scenario to work no matter the order of unpacing and configuring!

Have a look at the dovecot package!

 - Jonas

-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20060819/2f08d77c/attachment.pgp