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

[Paul Boddie]

On Saturday 9. April 2016 15.59.28 Jonas Smedegaard wrote:
> Quoting Paul Boddie (2016-04-09 14:08:29)
> > (Before I forget, and given that this is a "groupware weekend", I will
> > also try and dig up my Thunderbird/Lightning extension for reading
> > Web-based free/busy information and consulting the LDAP FBURL
> > attribute in order to know where to read such information from. It may
> > be of interest to the Icedove/Iceowl participants.)
> 
> Ohh, that would really be wonderful!
> 
> (especially, for my part, if those notes also reveal approaches usable
> without LDAP).

What I want to support, but which is (or was) awkward with the Thunderbird 
code base, is VCARD attributes for the same thing, since this allows peer 
exchange of such information instead of needing a central database.

[...]

> > As for the discussion about debconf and configuration files, which is
> > a whole new area of discussion,
> 
> Huh?!?  That is what we have been discussing all along!

No, I meant the concrete activities of software that can parse, modify and 
update different configuration file formats, potentially for files belonging 
to other packages, which we agree isn't something that should be done in 
general. For example, I had some code to parse the Erlang-based configuration 
for ejabberd and to modify settings. Similarly, I had code to do the same with 
the Roundcube and Dovecot configurations.

This really isn't all that relevant here, though, but I thought I'd provide 
some background on what I'd seen done before.

> > I looked into this a bit when working with the Kolab packaging, and I
> > even wrote some simple Python libraries to inspect and modify various
> > different kinds of files. But aside from the policy implications, it's
> > really not a nice thing to do anyway. That's when I really appreciate
> > the "whatever.d" approach where you can isolate each fragment of a
> > package or system's configuration.
> 
> Chopping configuration into pieces sensible to enable/disable as a whole
> is nice if possible.  That is generally referred to as conf.d approach.
> 
> For places needing more detailed setup - e.g. adding a maildomain - we
> have the debconf approach.
> 
> The "ship non-working configuration mandating adaptation by hand" is the
> worst way to ship a package.  Possible, and used in practice, but
> discouraged: One of the features Debian have been excelling at for many
> years is that daemons are working and turned on by default, not only
> compiled and thrown into place as (I have heard still) is the case for
> Redhat and other distros.

Agreed.

> > Now, if there were a way of saying at a system level, "integrate
> > Postfix with Cyrus using LMTP" with the necessary recipe being run
> > that copies files into place, enables things, maybe verifies users and
> > groups (thinking of the above bug report about Cyrus and LMTP), and
> > does all this in a Debian-approved way, that would eliminate a lot of
> > the "how to" following that otherwise has to be done manually. But I
> > suppose that the mechanisms need to evolve to make this a possibility.
> 
> There is such approach.  It requires coordination across packages, and
> likely involves both a) conf.d approach (for parts passing across
> packages) and b) debconf (for details of each package) and c) package
> selection (e.g. imip-agent-lmtp instead of imip-agent-smtp) for
> structural choices.

Right. As far as I understand, packages that provide integration options are 
acceptable and normal - consider the various postfix and dovecot packages for 
things like LDAP - but such packages must not enable themselves by changing 
their "parent" packages' configuration, or at least not silently. So, 
splitting imip-agent up into optional configuration-specific packages would be 
fine as long as those packages didn't try and "take over" upon being 
installed, or at least only offered to help (and even then, I'm not sure how 
desirable that would be).

> It won't happen if noone pushes to achieve it.  It won't happen if
> waiting for Debian: We are Debian - you included!

Well, I'll give such matters some thought, but in the meantime I'll make an 
archive available as a stable packaging target - maybe just starting with the 
existing one, for which I'll provide a signed checksum - and look into some of 
the other things you've mentioned.

Thanks for all the encouragement!

Paul