Bugzilla Bug 198633

# portageq owners / /usr/share/man/man8/imapd.8.bz2
net-mail/cyrus-imapd-2.2.13-r1
        /usr/share/man/man8/imapd.8.bz2
net-mail/courier-imap-4.0.6-r2
        /usr/share/man/man8/imapd.8.bz2

*shrugs* ... would it make sense to add blockers, so both packages are blocking
each other?

Another thought: how many people would try to install (or even run) both imap
daemons on one box? 

Well, I tried to remove Courier-IMAP but it was pulled back by
dev-libs/cyrus-sasl. According to the SASL ebuilds, the authdaemond flag
triggers a dependency on net-mail/courier-imap or mail-mta/courier. Of course I
already have a MTA which blocks Courier so Courier-IMAP is the only choice
left. This was probably added to allow Courier users to uses the IMAP
authentication backend of saslauthd. Kinda annoying since I actually use the
LDAP one.

Redefining the use falgs for dev-libs/cyrus-sasl could help here. It would also
allow one to get ride of those annoying error messages for unused auxpropfunc
backends in /var/log/auth.log without deleting the unwanted libs manualy. But
maybe I should open another report just for that.

Ping!

Could someone from net-mail comment?  It probably doesn't make too much sense
to have multiple imap daemons installed at the same time anyway, does it?

(In reply to comment #4)
> It probably doesn't make too much sense
> to have multiple imap daemons installed at the same time anyway, does it?

I can't think of *any* reason it would make *any* sense to run multiple imapd
daemons (plus which use a totally different data storage) at the same time ...
As I mentioned above we could add blockers to indicate formally that running
different imap servers at the same time isn't supported in any way (which
should be obvious though) - but from my pov this type of problem only occurs if
users are trying to do things which they wouldn't do if they're exactly sure
about what they are doing. 

Alright, so adding a blocker on virtual/imapd for everything that provides
virtual/imapd is fine?  I'll go ahead and do that if no one has any objections
(or if someone goes and does it before me, that's fine too)

I think so - but i'd like to get some input from other people maintaining some
kind of imapd packages ...

(In reply to comment #6)
> Alright, so adding a blocker on virtual/imapd for everything that provides
> virtual/imapd is fine?  I'll go ahead and do that if no one has any objections
> (or if someone goes and does it before me, that's fine too)
> 

please go ahead - either no one has any objections or no one is interested
that.

This should be all done now.