Bugzilla Bug 222157

enterprise portage # qfile /etc/mail/mailer.conf
net-mail/mailwrapper (/etc/mail/mailer.conf)
mail-mta/ssmtp (/etc/mail/mailer.conf)
mail-mta/exim (/etc/mail/mailer.conf)

well... duh!
This is a testing chroot where I have collision protection disabled, still they
don't block each other in any way. It doesn't seem right to me..

I just committet ssmtp-2.62 and dropped the mailwrapper use flag and it's
functionality according to
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg25623.html

(In reply to comment #1)
> I just committet ssmtp-2.62 and dropped the mailwrapper use flag and it's
> functionality

I believe that dropping the mailwrapper support and USE flag could lead to real
trouble. I noticed that when ssmtp-2.62 suddenly tried to install
/usr/sbin/sendmail. Let's have a look at several scenarios.

1. With mailwrapper support and without collision protection.
The mailer packages install a mailer.conf into /etc/mail, where it's config
protected, so the admin can then decide whether or not he wants to enable the
newly installed mailer or rather keep everything as it was.

2. With mailwrapper support and with collision protection.
This is pretty much the scenario outlined in comment #0, I guess. The admin
gets notified that several packages would want to write that config file, but
as it's config protected the admin has the last word. So after noticing that's
the only change, he might disable collsion protection for just that emerge and
find himself in scenario 1. Some notice that a collision on this file is to be
expected would make things easier.

3. With mailwrapper support suddenly gone and no collision protection.
The admin will not be asked any questions, will not get the chance to edit some
configuration file, but without all that, some package is suddenly overwriting
the sendmail binary itself, and with it probably the currently running system
mailer. On a production system, this will entail all kinds of trouble.

I very much liked the idea of mailwrapper, so it would be best to see some
progress on bug #158003 and get all mailers to properly support mailwrapper.

If you are determined that mailwrapper has to die, you should ensure that every
incarnation of a package that used to have a mailwrapper USE flag blocks
mailwrapper after that use flag is gone. Only in this way can you prevent users
from trashing their setup on mailwrapper-enabled systems. This way, Admins have
to unmerge mailwrapper manually, which will lead them to decide for one mailer,
and one alone.

I think you should also figure out all the mailers and the conflicts occurring
between them if you don't use mailwrapper. Especially packages installing
sendmail should block one another.

As for the case of mailwrapper enabled systems with collision protection, I
agree that the current handling with collisions is not nice. One way to go
would be to change the implementation of collision protection so that it won't
mind config masked files. After all, those will get reviewed by the admin
anyway, so it's all right for different packages to have different ideas of
defaults. The other way would be bug #158003 to take a direction with one
config file for each mailer and a configuration package to build the master
configuration from these.

(In reply to comment #2)
> I very much liked the idea of mailwrapper, so it would be best to see some
> progress on bug #158003 and get all mailers to properly support mailwrapper.

Given the fact that there is *no* progress on #158003 for 1,5 years plus there
was a discussion on the -dev mailinglist nearly 9 months ago with the effect
that noone is interested in it (plus not interested in maintaining it) and
noone objected to remove mailwrapper support, mailwrapper is to be considered
dead. Instead of keeping a broken and unmaintained mailwrapper the *much*
cleaner option is to remove it.

> If you are determined that mailwrapper has to die, you should ensure that every
> incarnation of a package that used to have a mailwrapper USE flag blocks
> mailwrapper after that use flag is gone. Only in this way can you prevent users
> from trashing their setup on mailwrapper-enabled systems. This way, Admins have
> to unmerge mailwrapper manually, which will lead them to decide for one mailer,
> and one alone.

Agreed, I just added the block on net-mail/mailwrapper to CVS.

> I think you should also figure out all the mailers and the conflicts occurring
> between them if you don't use mailwrapper. Especially packages installing
> sendmail should block one another.

That's happening for a long time, each package providing virtual/mta blocks
every other package which also provides virtual/mta.

(In reply to comment #3)
> mailwrapper is to be considered dead.

I'll mourn its loss, but it's not in my power to revive it.

> That's happening for a long time, each package providing virtual/mta blocks
> every other package which also provides virtual/mta.

ssmtp-2.61-r2 contained both the PROVIDES and the blocker. ssmtp-2.62 has
neither.

In my latest emerge -u world, I noticed that net-mail/mailwrapper is blocking
mail-mta/ssmtp-2.62-r3. Going through the changelog brought me to this bug.

It's unfortunate that mailwrapper support is dead. The MTA I use is not in
portage. I maintain my own ebuilds for Citadel. Citadel is a nice MTA. However,
it's sendmail command is rather limited. Up to this point, I'd been using
Citadel together with ssmtp via mailwrapper. Now I'll need to remove ssmtp.
Perhaps I can bring it in as a patch against Citadel, using the single citadel
ebuild.

I do have one question about ssmtp. Why does it provide virtual/mta? It's not a
MTA. It only provides a replacement for the sendmail command. It can't receive
or deliver mail. 

actually ssmtp can receive an email on the command line and deliver it to a
remote  SMTP server. so technically it replaces /usr/binm/mail

This problem could be imho solved by packages using /etc/mail/<package>.mailer
instead of /etc/mail/mailer.conf and calling eselect:

# eselect mailer list
Available mailer.conf profiles:
  [1]   msmtp
  [2]   ssmtp
# eselect mailer set ssmtp
# ls -l
total 12
-rw-r--r-- 1 root root 809 Aug 19  2008 aliases
lrwxrwxrwx 1 root root  12 May 26 15:44 mailer.conf -> ssmtp.mailer
-rw-r--r-- 1 root root 279 Aug 25  2008 msmtp.mailer
-rw-r--r-- 1 root root 349 Aug 21  2008 ssmtp.mailer

... similar for exim or anything. This way we _can_ have installed more
packages and I need to have each one on some systems.

so, I think this is a problem of packages misusing mailwrapper and that they
should be fixed to use it the correct way...

I'm all for the eselect, but without a fixed mailwrapper it all makes little
sense.

bug #158003 actually states that mailwrapper is going to be removed, so
mailwrapper support in Exim will be removed now.

fixed in 4.69-r3, should become candidate for stabling soon.