Arch Linux

I suggest to talk to the dovecot maintainer to coordinate releases.

Moreover I can't find any clue on http://pigeonhole.dovecot.org that version 0.3.1 requires exactly this version (2.1.8) of dovecot. They claim that pigeonhole-0.3.1 is for dovecot 2.1 in general and not only a specific minor version. Though I did not test this on my own. :)
So it might be sufficient to adjust the dependency requiements of this package.

Michael,
It looks like this could but it doesn't work. On a testbox I upgraaded dovecot to 2.1.9 and it fails to start:
root@homsrv: ~# rc.d start dovecot
:: Starting dovecot daemon [BUSY] doveconf: Error: Module is for different version 2.1.8: /usr/lib/dovecot/modules/settings/libmanagesieve_login_settings.so
doveconf: Error: Module is for different version 2.1.8: /usr/lib/dovecot/modules/settings/libmanagesieve_settings.so
doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: protocols: Unknown protocol: sieve
[FAIL]
root@homsrv: ~#

So it seems that it needs a rebuild on every dovecot upgrade.

Is this still an issue?

With every dovecot release this is an issue because pigeonhole is (if I'm right) maintained by a different person then dovecot. Unfortunately they must be released together even if the pigeonhole version doesn't change, a rebuild of the pigeonhole package is needed. This info is on the dovecot site as well, but I can't find a good reason why it is made this way. Anyway, both maintainers need to sync their work.
The current dovecot 2.1.10-1 and pigeonhole 0.3.3-1 work together.

I see, thanks. Perhaps both maintainers could co-maintain both pigeonhole and dovecot? Just a suggestion.

Hi,

Just a bit of background: I started looking after pigeonhole way back when it was in the AUR, and eventually I moved it to [community] since it was well used. And yes, an issue is that a pigeonhole binary built against a previous version of dovecot leads to mail delivery failure. Many people would forget to rebuild pigeonhole each time dovecot was updated and not notice that their mail was not arriving for a while. Hence, moving it to [community] with a hard dep against the current version of dovecot also had the effect that the worst that would happen for users is that they would not be able to update their system until dovecot was rebuilt and the versions were re-aligned. IMO this was preferable to missing mail and others seemed to agree in a brief discussion on the mailing lists.

But yes, it seems that the ideal solution (and the best option for users) would be that both packages are built and released together. Since I'm a TU and not a Dev, I can't touch dovecot, which is in [extra] (and Andy does a great job there anyway, and I woudln't want to interfere). In order to achieve this, perhaps Andy you could either:

1) Rebuild and re-release pigeonhole when you push a dovecot update, and I will continue to maintain it in all other ways, or

2) Maintain them together in [extra]?

I'm happy to help however is useful. I'm also totally fine with giving up pigeonhole maintainership if Andy thinks it's better to maintain them together.

I don't package to the community repo. I'll move pigeonhole to extra along the next dovecot update.

But I personally don't use pigeonhole at all and don't plan to do so. Any help in the future is welcome.

Thanks, Andy. I think that makes the most sense given the constraints. (Really, it seems silly to me that this constraint exists, but I suppose it must be there for a reason.)

I'm happy to help however I can. Let me know if you want me to do some testing, for example.

Can we close this?