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

Sat Apr 9 13:59:28 UTC 2016

Quoting Paul Boddie (2016-04-09 14:08:29)
> On Saturday 9. April 2016 11.10.10 Jonas Smedegaard wrote:
>> Paul: Please make a formal tarball release of your project.  If you 
>> feel it is very imperfect yet, then make it a version 0.0.1 or even 
>> 0.0.1alpha00001 - just please make a release, as that is far easier 
>> to work with than me doing an unofficial snapshot from git from 
>> Mercurial.
>
> OK. I'll do that shortly.

Great!

>> I believe that for for moving towards a (possibly future) situation 
>> of automating, the location for not-enabled-by-default snippets 
>> should be tied to the consuming daemon - like done with apache in 
>> recent time.
>
> Alright. Having read that bug report you mentioned, as well as 
> considering the need for people to coordinate configuration across 
> packages (which I imagine is what Debian-Edu and FreebomBox want to 
> do),

Integration across packages is what Debian in general wants (although 
quite possibly large part of Debian - including many developers - may 
not realise it).

What Debian-Edu have done is to paper over the problem in ways violating 
Debian Policy, as documented in bug#311188 - also documenting how 
release managers treats it as "not our problem because Debian-Edu is not 
Debian.  Outside of the bugreport, Debian-Edu eagerly pushes for 
recognition as a Debian Pure Blend - i.e. integral to Debian.

I fear (but as mentioned have given up on following closely) FreedomBox 
may have or grow similar flaws as documented in bug#311188: Petter 
Reinholdtsen - lead developer of Debian-Edu - have been active in 
developing FreedomBox the past year. His opinion (recorded on video at 
Debconf in 2011) is that bug#311188 is not a serious problem.

> I suppose that some kind of mechanism will eventually be developed in 
> Debian to allow this in a way that doesn't surprise or confuse 
> administrators. (I suppose this is where all those cloud-related 
> deployment tools come in, but I've kept somewhat away from them for 
> now.)

No! Lack of integration is a chicken-and-egg problem: Debian is waiting 
for a "real need" for infrastructure be really needed to implement, 
whereas your attitude of waiting until in place means that your need for 
integration goes unnoticed!

> Ah, OK. I remember you promoting it at FSCONS a few years ago, and I 
> thought you might still be involved.

I _am_ still involved with the FreedomBox project.

What I am not - and never was - involved in is writing code specific to 
FreedomBox for either generating image (I am instead developing the 
Debian generic Boxer tool) or Plinth admin interface (I strongly believe 
there should be *no* admin interface).

> I think I have realised that there might not be the support for 
> coordination (or maybe they call it "orchestration" in things like 
> chef or puppet) in Debian as such, which is what I was hinting at, 
> hoping that there might be some answers in all that policy 
> documentation.

There are several ways to integrate across packages. But none of them 
happen automagically - they all require coordination between the 
involved parts, e.g. bugreports filed against an MTA when the need for 
an interface is identified!

>> If you look at the "Other external delivery methods" section of 
>> postfix master.cf - how it contains support for mailman.  Search its 
>> changelog file for "mailman" and you'll find bug#297869.  That's how 
>> to approach it - and our suggesting support for a generic lmtp 
>> transport is far more sensible than that package-specific transport.
>
> OK. I defer to your greater experience in such matters. I was merely 
> concerned that the maintainers might object on the grounds that 
> everybody might start asking to add random transports and thus "bloat" 
> the configuration. Then again, it might encourage people to develop a 
> better mechanism for managing the configuration (some kind of 
> master.cf.d, perhaps).

Maybe it is bloat: The postfix maintainer might respond to a bugreport 
with "thanks for the bugreport, but no, that is bloat and won't be 
implemented" - that is indeed a possible outcome.  Not filing the 
bugreport is, however, a form of "hiding a problem" which we are porud 
to not do in Debian ;-)

> Actually, this reminds me of the lmtp and Cyrus bug report that I 
> believe I mention in the documentation:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494746
>
> Here, people just want stuff to "just work", but one gets the 
> impression that the maintainers aren't interested in letting that 
> happen.

I disagree: As I read it, package maintainers don't say "no, never" but 
"no, not convinced this is a common need"!

> The result is that people will then make mistakes only to be told that 
> they did it wrong, of course.

There are two "tracks" in the bugreport: a) improving integration across 
packages, and b) how to best integrate (whether done by packages or by 
hand.

> Mailbox integration (as I call it) is also mostly peripheral to 
> imip-agent: a mechanism must exist to allow the software to deliver 
> messages to recipients, but this can be done using "local SMTP" rather 
> than LMTP. Indeed, when I figured out how to route mail locally via 
> SMTP, I was rather pleased with myself, particularly in light of 
> complications like the above.

If some approach is possible without changing other packages, then we 
can do that by default and document as example files how a mire tight 
integration needing hand-tuning is possible to do by hand.

If such tighter integration is beneficial on a larger scale, not only 
specifically for the tiny userbase of postfix+imip-agent users, then it 
still makes sense to bug postfix (and exim etc.) about it - that is then 
just not holding back the progress of packaging imip-agent.

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

>>>> 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. ;-)
>>
>> Where?!? I don't recall that bit.
>
> It's the "court notice" near the end (and there's also some "delivery" 
> spams, too):
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188#394

Ohh :-D

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

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

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

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

 - Jonas

-- 
 * 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/dc892723/attachment.sig>