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.
