Emerging exim, the ebuild also installs a `/usr/bin/mail->../sbin/exim' symlink, which will overwrite the `/usr/bin/mail' executable installed by `nail'. When using `mailx', the mail binary is installed into `/bin'. However, there are a lot of programs/scripts that expect to find `mail' in `/usr/bin' and thus will pick up the exim binary instead...resulting in the following error message: ---- Exim is a Mail Transfer Agent. It is normally called by Mail User Agents, not directly from a shell command line. Options and/or arguments control what it does when called. For a list of options, see the Exim documentation. ----
*** Bug 28702 has been marked as a duplicate of this bug. ***
*** Bug 32068 has been marked as a duplicate of this bug. ***
handing these over to Jay
Fix added to exim-4.31.ebuild shortly available in portage. Does this provide what you wanted?
doesnt work for me $ mail Exim is a Mail Transfer Agent. It is normally called by Mail User Agents, not directly from a shell command line. Options and/or arguments control what it does when called. For a list of options, see the Exim documentation. $ mail -s test hww@localhost exim abandoned: unknown, malformed, or incomplete option -s
removing the symlink should be safe, and the ebuild should be checking for the precense of /usr/bin/mail before creating the symlink. === quote from ebuil === if \[ ! -e /usr/bin/mail \] && \[ ! -e /bin/mail \]; then einfo "Installing symbolic link /usr/bin/mail -> /usr/sbin/exim" einfo "If you install mailx please *REMOVE* that link, that way" einfo "scripts will use the mailx-binary instead of the exim-binary." dosym ../sbin/exim /usr/bin/mail else einfo "NOT installing symbolic link /usr/bin/mail -> /usr/sbin/exim," einfo "because you already have a mail-binary." === end quote from ebuild === I don't know if mailwrapper could be enhanced to provide support for multiple MUAs as well MTAs
3 problems: 1. exim is not a MUA in the first place. Irregardless of users succeeding in passing headerless message bodies to exim, that's not how things are supposed to work. Exim is not a MUA. BAM! (see comment #1 and bug #28702 'exim is not a mua') 2. The quoted portion in comment #6 makes the ebuild not really package safe: what happens if you build exim on a machine w/o mailx, nail, or mailutils; and later unpack it on the same or different box and /usr/bin/mail exists? BAM! (see bug #36486 comment #5 'exim-4.30 version bump') 3. No distribution known to mankind ever installs that particular symlink. Exim is not a MUA. BAM! (see POSIX and Single Unix Specifivication V3 for more details on the 'mail' utility)
As far as the mailx goes, that was my fault for forgetting to remove symlinks when I revamped the package. However the binary belongs in /bin, where it's always been. Scripts, etc, calling mail from /usr/bin are broken.
How are they broken? RH (and derivates) are the only ones who have mail(x) in /bin. Suse (used to?) have a /bin/mail symlink pointing at /usr/bin/mail. In Debian, Slackware and the various BSDs (where mailx originally comes from) there is no /bin/mail at all (this info thanks to <bartron[at]gmx[dot]net> back in September 2003 when this bug and bug #28702 were first opened; but still true to the best of my knowledge). Since RH does have a /usr/bin/mail symlink pointing at /bin/mail, /usr/bin/mail is in fact THE ONLY PORTABLE path that is guaranteed to work on all POSIX-like OSs in wider use. But the real issue, in Gentoo, is, /usr/bin/mail either does not exist at all or is a symlink to the wrong prog, depending on the order exim and mailx are emerged.
Well, first off, caps will get you pretty much nowhere. I can say I've already owned to leaving the syms on the mailx package,which belong where they are. Secondly, you were slightly misinformed by bartron. mail(x) was in /bin in AT&T System V, and when adopted by BSD went to /usr/ucb/mail. True enough Debian, Slack and the rest have it in /usr/bin, but following in the footsteps of distros we're not inclined to use in the first place doesn't provide an elegant solution,either. I would wonder what you hope to accomplish by having multiple MTA's on your system, because without you sharing this information, how can you hope for a solution? Symlinking /usr/bin/mail to /sbin/exim will jack up nail.. Symlinking /usr/bin/mail to /bin/mail|Mail|mailx will also jack nail... Seems the easiest solution would be to have each package install the sym and block other MTA's. Or the correct way would be to remove the /usr/bin/mail sym in exim, and if you insist on using scripts which call for /usr/bin/mail install nail and leave the others alone.
I know exim is an MTA, i never suggested it was, my musing was for expanding mailwrapper to know about mailx/nail et al. As Chuck suggests, I'm going to remove that particular symlink from the ebuild entirely and let the user decide if they want to symlink it or not. (oh and "BAM" really is quite obnoxious...)
Still not sure how to interpret comment #10 fully, but here's are my thoughts (still a bit shocked about the footsteps comment): - where was I misinformed? All he did was provide me with bin packages and build scripts of the various distributions from past to present from his huge archive; only hard facts. The mailx package used in Gentoo is taken almost directly from Debian, who in turn takes it from OpenBSD. - there is no /usr/ucb in BSD; mail=Mail=mailx is in /usr/bin - some hybrids have both, /usr/bin/mail(native) and /usr/bin/mailx(BSD semantics). /usr/ucb/Mail and /usr/ucb/mail are symlinks to /usr/bin/mailx (SunOS 5.9). Doesn't change the fact there's a /usr/bin/mail that satisfies all requirements set by POSIX. - two different binaries with the same name in default path (/bin and /usr/bin) is a big NO NO NO NO! - mailwrapper on BSDs's reason is not primarily to have multiple MTAs at the same time; in BSD sendmail in /usr/sbin comes as part of the base system and can't be removed; and since mail clients refer to /usr/sbin/sendmail and alternative MTAs, such as exim, go into /usr/local, mailwrapper's primary purpose is to allow clients access to alternative MTAs; a restriction that does not exist on linux systems at all. - /bin is reserved for binaries esential for bootup and system recovery (in times of live CDs more the former than the latter). mailx requires /var and /usr operational to work (/usr/sbin/sendmail and mailspool); won't work if any of these dirs are broken or not mounted yet. - RedHat may have mail in /bin, but there's no OS that has Mail (note capital M) and mailx in /bin. - Exim being an MTA is not a MUA and does not meet POSIX requirements. I'm not repeating this over and over just to rub it in (even if it sounds like this by now); but contrary to popular beliefs mailx is not just a wrapper around sendmail but a full-featured mail client (well, at least by the standards at the time it was written). Why would enyone want to call a MUA by the name of an MTA? So what do I want? (Or rather, what's best for your users? Well first it's not my bug and second off after 9 months of responselessness on this bug we're using our own custom ebuilds by now, but here's what I think): 1. remove that dreaded symlink from exim, according to bug #5096 it was intruduced at times when there was no mailx in Gentoo; it was wrong back then and is still now. 2. put mail, Mail, and mailx in /usr/bin, /bin/mail being a symlink to ../usr/bin/mailx. Reasoning: 2.a mailx and nail serve the same purpose, so they should provide the same binaries in the same places. 2.b as noted above, mailx is not operational w/o /usr and /var/mail (and possibly /home) mounted, so there's no reason to make the root partition unneseccarily bigger. 2.c consistant with what other dists do. Instead of "not following in the footsteps of distributions noone's gonna use" (paraphrasing), it should be "Combining the best of all worlds". Sounds much better. 3. make mailx and nail block each other. BAM?
first, a clarification, there's a typo at the start of comment #11 "I know exim is an MTA, i never suggested it was," should have been, "I know exim is an MTA, i never suggested it wasn't,". please accept my apologies for that one. I'm not going to respond to most of the comments, as I don't know the background. I personally agree with most of them, but I'm going to address the original bug report. The symlinks will be removed from the ebuild (as i said in comment #11), in fact they've already been removed from the ebuild that I have in my cvs overlay, ready and waiting for the release of the latest exiscan patch for 4.40. Once this has happened, then I'm going to try and find the owner of mail/mailx and ask them to handle this bug. The comment about "(oh and "BAM" really is quite obnoxious...)", to me ending your sentances with BAM, makes it sound like you're hitting someone.... not an enjoyable pasttime for many people.
Misinformed- to be incorrectly informed. I'm not going to go into the lengthy explanation, as you only go back to SunOs, I know from prevoius experience the history. But since you're not gonna believe me, you could read the nail homepage for the history lesson. I, also found the bam thing to be annoying, and probably some sort of trademark infingement, as I sincerely doubt that you're Emeril.I'm removing my cc as this has long since become pointless, Colin's got it under control, and if he wants help, he's got my email:)
closing this bug, symlinks have been removed, if you need to re-open, please be very specific why, this isn't the easiest of bugs for me to read.
