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

[Paul Boddie]

On Saturday 9. April 2016 00.21.49 Jonas Smedegaard wrote:
> Quoting Paul Boddie (2016-04-08 22:43:57)
> > 
> > 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.

I guess that's probably good enough for now, if I pretend to understand what 
that really means from having seen it in use. ;-)

> > 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.

I was more or less thinking that one would copy files into somewhere neutral - 
I don't know if /usr/share/imip-agent is sensible or strictly forbidden, but 
really somewhere that isn't, say, /etc/postfix (or /etc/apache2/sites-
available, for that matter) - and then the administrator could reference this 
from within the other package's configuration, typically by using a file that 
does some kind of include, if supported, or just copying it into a suitable 
place otherwise.

I guess stuff like this is done for FreedomBox, so perhaps I should take a 
look at that. You appear to be an expert there as well. :-)

> > 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?

I was probably referring to the installation of sample files that the 
administrator then needs to edit and enable, rather than anything particularly 
exotic. I can think of many happy hours configuring things like Dovecot where 
there are lots of configuration files referencing other packages and systems 
that may or may not be installed, but where the maintainers presumably thought 
that such files would nevertheless be useful.

> 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.

I don't even dare to file such bugs/patches, partly because I'm no expert with 
MTAs, partly because the MTA people don't always seem that approachable, and 
partly because even that patch to master.cf might be regarded as too specific 
to a particular configuration choice.

> 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).

Exim uses a special update script that lets the administrator maintain 
fragments in separate directories that then get concatenated and given to 
Exim. This means that it can be configured in a flexible way.

The whole "LDAP versus something else" choice starts to move quite far outside 
mere configuration and into the realm of policy. In the conf/exim and 
conf/postfix directories, I've separated the policy-related stuff into 
"simple" and "ldap" directories, and these lie at the outermost reaches of the 
basic configuration activity.

With regard to configuring LDAP itself, it's really outside the scope of all 
this altogether: I just included some examples to help other people like me 
get started, given that my LDAP expertise was minimal not that long ago (and 
maybe still is).

> > 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!

To an extent, though, I'll be writing tools anyway because they'll be used for 
testing and generally getting things done.

> > 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.

That's an interesting discussion! I see things got so serious that it was 
about to end up in court. ;-)

Paul