On systems with a custom install of sendmail, and sendmail injected into portage, upgrading mod_php nevertheless forces the install of ssmtp in place of the sendmail binary in /usr/sbin - without any apparent warning it's doing this evil act, either. mod_php may have some use for something in ssmtp, but it should _not_ force ssmtp to be installed in place of an existing system mail agent. Reproducible: Always Steps to Reproduce: 1. 2. 3. # emerge info Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.8.1) ================================================================= System uname: 2.6.8.1 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -fprefetch-loop-arrays -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -fprefetch-loop-arrays -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X apm arts avi berkdb bitmap-fonts cdr crypt cups encode esd foomaticdb gdbm gif gpm gtk gtk2 guile imlib java jpeg kde libg++ libwww mad mbox mikmod motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xprint xv zlib"
Similar problem three months later. Any ideas?
PHP only depends on a few virtuals, some of which default to ssmtp in the profiles. if you inject a package that provides some virtuals, you need to inject the virtuals as well! Just injecting the package does not satisfy the virtuals.
Injecting virtuals? If this is something we need to do, I don't recall it being advertised in the docs. Not that I've looked for it, but in the normal course of installing and running Gentoo - on a number of systems for well over a year - I've never been introduced to a notion of injecting virtuals. I'm not quite sure what it even means. What happens here is that the sendmail binary itself gets overwritten - not a symlink (although what it gets overwritten by is a symlink). It's easy enough to recover just if you have a backup copy of the sendmail binary. But even so it's really ugly behavior to have a major daemon disabled, even if only for the short time to copy the backup binary back into place. It would be quite easy for the install routine to test for whether the file sendmail exists, and whether that file is a binary, and not overwrite it perhaps in either case, or at least if it is a binary. If it's there in either case, a mail agent is installed, and that's all PHP needs to know - that an agent is installed which will handle calls to "sendmail."
Any package that provides the mail agent of /usr/sbin/sendmail should PROVIDE="virtual/mta", so that we can DEPEND="virtual/mta" and have a package brought in if it isn't present, instead of just throwing and error and stopping the emerge process (as would happen in your suggestion when PHP tries to build). I double-checked about injecting virtuals with the portage folk as well. [01:22] <robbat2> any portage folk here care to answer a question relating to treatment of virtuals when injecting packages? [01:23] <jstubbs> robbat2: nothing is done automatically. [01:23] <robbat2> so virtuals must be injected as well as the base package then? [01:24] <jstubbs> robbat2: "cat/pkg-ver" to /etc/portage/profile/package.provided and "virtual/foo cat/pkg" to /etc/portage/virtuals [01:25] <jstubbs> robbat2: you'll get a deprecation notice on /etc/portage/virtuals, but it's safe to ignore.. if you have no installed packages supplying virtual/foo you can move it to its profile/ counterpart with no difference in functinoality. [01:26] <jstubbs> if you do have a virtual/foo provider installed, portage/virtuals and portage/profile/virtuals are different. [01:26] <robbat2> well the user has a really custom build of an mta, and previously did inject the package itself, but virtual/mta came up and bit them as not being installed so in your case with a custom sendmail: mkdir -p /etc/portage/profile echo 'mail-mta/sendmail-VERSION' >>/etc/portage/profile/package.provided echo 'virtual/mta mail-mta/sendmail' >>/etc/portage/virtuals
Hi Robin, Thanks for the instructions on how to "inject virtuals." Has this been added to the public documentation somewhere, or does the next person to need this have to first trip over it and then find it in the bug reports here? Should I file a documentation bug? Also, just as a curiousity, I don't follow why the method I suggested would have to stop the PHP installation. The logic would be "if not exists /in/path/sendmail then depends ssmtp else continue install" - or perhaps the narrow test "if not exists binary file /in/path/sendmail". Any mta that responds like sendmail works for PHP, doesn't it?
PHP usually fails if /usr/[s]bin/sendmail isn't present. Yes, please do file a docs bug. Your method there would be fine is we could check conditions at dependancy generation time, but it would also be even slower than the current stuff (which is why we don't do it). For speed of dependancy generation, we require that DEPEND/RDEPEND and a number of other variables give exactly the same result every time the ebuild is sourced, no matter what machine is it being run on. So because of this we can't check for the binary for calculation of dependancies - they need to be constant (hence the virtual/mta). The name is the only relation between /usr/sbin/sendmail and the Sendmail package. It used to be with sendmail when sendmail was the only MTA out there, but now every MTA provides their own /usr/sbin/sendmail for injecting email.
I found emerging mailwrapper satisfied whatever it was that the mod_php and php ebuilds were looking for. I run completely mailless boxes, so I don't want MTAs installed, not even ssmtp.
