[Calendarserver-discuss] Free Software calendaring and groupware (in and beyond Debian)

[Jonas Smedegaard]

Quoting Paul Boddie (2016-04-08 22:43:57)
> On Friday 8. April 2016 22.02.03 Jonas Smedegaard wrote:
>>> (On the topic of package configuration, I did try and make the Kolab
>>> packaging work with debconf, which isn't something I would really like
>>> to do again in the near future, but maybe debconf interaction isn't
>>> really necessary for something as simple as this work.)
>>
>> Right, I may introduce debconf later (if nothing else then for the 
>> SQL stuff when you release that, by use of dbconfig-common), but 
>> expect it to *not* be necessary for an initial working package 
>> release.
>
> The basic installation (tools/install.sh) involves only the program 
> files plus filesystem resources, which is a common Debian phenomenon 
> in my experience. It does put things in /etc/imip-agent, which might 
> not be done in the best way because something should be checking for 
> changes (maybe a debhelper thing).

Right - I intend to leave your configfiles as dpkg conffiles at first.


> How the software plugs into the mail configuration does involve 
> decisions, but even then it should be possible to install some files 
> somewhere and have the mail system reference them if configured to do 
> so, deferring that configuration to a later time.

Apache can handle that, but MTAs? I am only familiar with postfix 
myself, not exim, but am surprised if any of them support hooks 
reliably.


> Again, I've seen various Debian packages do that. Nothing actually 
> gets installed into the configuration of other software: that's an 
> administrator decision.

Hmm - which software does smart integration like that?

What I expect to do is file a bug (with a patch) against postfix to 
include in its default master.cf your snippet for a generic lmtp handler 
- that seems a clever approach to me, and sensible to support.  Then I 
would simply leave the rest as example scripts and accept patches for 
more integration from others actually understanding those parts (I am 
not very familiar with ldap, and as mentioned not familiar at all with 
exim).


> There would be parameterisation required to make some of the mail 
> configuration files, and that might well involve interaction with the 
> administrator. I don't have a problem making simple command line tools 
> to help with this as they could always be invoked by debconf. I've 
> tried to make standalone tools (in the tools directory) for common 
> tasks.

I suggest you spend time on evolving your project instead of on writing 
wrapper tools for Debian integration.  I and others can easier work on 
integration, your time is best spent on evolving your nice code!


> Although there is a degree of integration required for the software to 
> be useful, at least we're not aiming to configure everything related 
> to it as well. (That was the challenge with the Kolab packaging and 
> trying to replace the notorious setup-kolab script.)

Attempting to configure other parts than the package itself is a no-go.  
See bug#311188 for a long-standing instance of that.


 - Jons

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/calendarserver-discuss/attachments/20160409/7d8a06b1/attachment.sig>