dev-lang/php unconditionally depends on virtual/mta I would like to request a use flag for toggling this dependency. The php configuration process already checks if sendmail is installed, and disables it internally if it's not found on the system. Reproducible: Always
I do not think this is a very good idea. Even with the proposed USE flag off, mail() would be available if an MTA is installed. Also, the default MTA is extremely lightweight and will not have any practical impact on a system.
I completely agree that it would be preferable to have a --without-sendmail configuration option, and if there's interest here my next step will be to begin working to have such a configuration option included in future versions of PHP. As for the impact of MTA on the system, I do acknowledge it's inconsequential in terms of space, compile time, and resources. I simply can't help but believe that a system which sends no mail, should not require any mail related packages be installed. I'm just being a purist about unused packages on my machines, if the Gentoo developer community does not feel this is worth changing, I will respect that decision.
Whilst I don't see much need for this myself, adding +mail (default on) to the ebuild and conditionally pulling in the virtual would make this possible with little impact to users. This way experienced users who really don't want it have the option to disable it. However, it opens up a can of worms where at this point any webapp which depends on php with mail support _should_ add dev-lang/php[mail] as a dependancy.
Sorry, but I still do not think this is a very good idea. Try asking upstream to add that --without-sendmail flag instead.
*** Bug 508938 has been marked as a duplicate of this bug. ***
(In reply to Ole Markus With from comment #4) > Sorry, but I still do not think this is a very good idea. Try asking > upstream to add that --without-sendmail flag instead. upstream says they dont depend on sendmail during compiling. this is a valid bug.
Please read the discussion.
(In reply to Ole Markus With from comment #7) > Please read the discussion. i did, have you?
(In reply to C.J. Wijtmans from comment #8) > (In reply to Ole Markus With from comment #7) > > Please read the discussion. > > i did, have you? I even reported it upstream already and got a reply.
I guess you did not. PHP does not depend on an MTA, but it, at compile time, checks the system for an MTA and compiles in mail support. It is not a flag that either disables or enables this check. See: http://us3.php.net/manual/en/configure.about.php
(In reply to Ole Markus With from comment #10) > I guess you did not. PHP does not depend on an MTA, but it, at compile time, > checks the system for an MTA and compiles in mail support. It is not a flag > that either disables or enables this check. > > See: http://us3.php.net/manual/en/configure.about.php and? If that is the case remove the MTA dependency or add a use flag. Simple.
Also it is exactly what Anthony and I have said.
(In reply to C.J. Wijtmans from comment #11) > (In reply to Ole Markus With from comment #10) > > I guess you did not. PHP does not depend on an MTA, but it, at compile time, > > checks the system for an MTA and compiles in mail support. It is not a flag > > that either disables or enables this check. > > > > See: http://us3.php.net/manual/en/configure.about.php > > and? If that is the case remove the MTA dependency or add a use flag. Simple. And I said I do not think it is a good idea and resolved it as WONTFIX. Status of this bug stands.
Your opinion is invalid.
(In reply to C.J. Wijtmans from comment #14) > Your opinion is invalid. Um, not when it comes to PHP in the package tree. I suggest you create an overlay with a PHP ebuild version that suit your needs.
(In reply to Ole Markus With from comment #15) > (In reply to C.J. Wijtmans from comment #14) > > Your opinion is invalid. > > Um, not when it comes to PHP in the package tree. I suggest you create an > overlay with a PHP ebuild version that suit your needs. Well i suggest a new dev then. Maybe Anthony.
(In reply to C.J. Wijtmans from comment #16) > Well i suggest a new dev then. Maybe Anthony. Seeing how most of your bug reports are failures, your suggestions ought not to carry much weight.
(In reply to Jeroen Roovers from comment #17) > (In reply to C.J. Wijtmans from comment #16) > > Well i suggest a new dev then. Maybe Anthony. > > Seeing how most of your bug reports are failures, your suggestions ought not > to carry much weight. gentoo is becoming a failure.
(In reply to C.J. Wijtmans from comment #18) > (In reply to Jeroen Roovers from comment #17) > > (In reply to C.J. Wijtmans from comment #16) > > > Well i suggest a new dev then. Maybe Anthony. > > > > Seeing how most of your bug reports are failures, your suggestions ought not > > to carry much weight. > > gentoo is becoming a failure. I might as well switch to bloatbuntu.
(In reply to C.J. Wijtmans from comment #19) > (In reply to C.J. Wijtmans from comment #18) > > (In reply to Jeroen Roovers from comment #17) > > > (In reply to C.J. Wijtmans from comment #16) > > > > Well i suggest a new dev then. Maybe Anthony. > > > > > > Seeing how most of your bug reports are failures, your suggestions ought not > > > to carry much weight. > > > > gentoo is becoming a failure. > > I might as well switch to bloatbuntu. Nobody is forcing you to use Gentoo. Clearly this problem should be resolved with upstream. You can file an upstream bug here: https://bugs.php.net/
(In reply to Matthew Schultz from comment #20) > (In reply to C.J. Wijtmans from comment #19) > > (In reply to C.J. Wijtmans from comment #18) > > > (In reply to Jeroen Roovers from comment #17) > > > > (In reply to C.J. Wijtmans from comment #16) > > > > > Well i suggest a new dev then. Maybe Anthony. > > > > > > > > Seeing how most of your bug reports are failures, your suggestions ought not > > > > to carry much weight. > > > > > > gentoo is becoming a failure. > > > > I might as well switch to bloatbuntu. > > Nobody is forcing you to use Gentoo. Clearly this problem should be > resolved with upstream. You can file an upstream bug here: > https://bugs.php.net/ Another person that cant read. I already filed a bug report and got a reply.
(In reply to C.J. Wijtmans from comment #21) > (In reply to Matthew Schultz from comment #20) > > (In reply to C.J. Wijtmans from comment #19) > > > (In reply to C.J. Wijtmans from comment #18) > > > > (In reply to Jeroen Roovers from comment #17) > > > > > (In reply to C.J. Wijtmans from comment #16) > > > > > > Well i suggest a new dev then. Maybe Anthony. > > > > > > > > > > Seeing how most of your bug reports are failures, your suggestions ought not > > > > > to carry much weight. > > > > > > > > gentoo is becoming a failure. > > > > > > I might as well switch to bloatbuntu. > > > > Nobody is forcing you to use Gentoo. Clearly this problem should be > > resolved with upstream. You can file an upstream bug here: > > https://bugs.php.net/ > > Another person that cant read. I already filed a bug report and got a reply. It would be helpful if you posted the upstream url.
All the ugly "C.J. being C.J" aside, there is something to say for replacing PHP_PROG_SENDMAIL with a PROG_SENDMAIL=/usr/lib/php$MAJOR.$MINOR/bin/sendmail (pointing to a simple wrapper script) and doing a PHP_SUBST(PROG_SENDMAIL) in configure.in. Matching that wrapper with a proper $PATH/sendmail should be trivial if done safely. But I'd change this bug's resolution to UPSTREAM if that's not going to be done.
https://bugs.php.net/bug.php?id=63891
In this particular case, even adding the mta to package.provided may help you, if you really, really want to get rid of the mta. Note I don't advise or support that.
(In reply to Matti Bickel from comment #25) > In this particular case, even adding the mta to package.provided may help > you, if you really, really want to get rid of the mta. Note I don't advise > or support that. In that case you might as well make sure you install a simple MTA and have mail delivered to /dev/null or do local delivery, since you're going to end up with a mail() function that will always fail one way or another.
The impact of having an MTA installed is much, much lower than having to maintain a distro patch. I suggest you rather take the fight with upstream.
(In reply to Jeroen Roovers from comment #26) > In that case you might as well make sure you install a simple MTA and have > mail delivered to /dev/null or do local delivery, since you're going to end > up with a mail() function that will always fail one way or another. If you go to such length to cripple mailing, I kinda assumed you have mail() in disable_functions. Which is also the upstream position in the linked bug. I don't see this changing.
(In reply to Matti Bickel from comment #28) > (In reply to Jeroen Roovers from comment #26) > > In that case you might as well make sure you install a simple MTA and have > > mail delivered to /dev/null or do local delivery, since you're going to end > > up with a mail() function that will always fail one way or another. > > If you go to such length to cripple mailing, I kinda assumed you have mail() > in disable_functions. Which is also the upstream position in the linked bug. > I don't see this changing. in other words install bloatbuntu or deinstall php?
(In reply to C.J. Wijtmans from comment #29) > in other words install bloatbuntu or deinstall php? If you think dev-lang/php _isn't_ bloated but a simple package like msmtp or ssmpt or esmtp _is_, then you will be in for a shock when you switch to what Ubuntu _doesn't_ consider to be bloated. Also, bashing one distro in the bug tracker of another distro is delightfully pointless. Also, setting virtual/mta up as package.provided has been suggested as an alternative. You should look it up in portage(5). There, we provided for you.
I see this gained some popularity all of a sudden. I have an issue open with the PHP upstream here to add a configure flag for evenutally reopening this issue: https://bugs.php.net/bug.php?id=63891 But since this has been a low priority issue for me, I haven't had a chance to work on a patch / pull request for php itself. A comment specifically for you C.J. Wijtmans, try to respect and understand the explanation given for this being a closed issue right now. The reason for rejection was stated, and there are clear actions that can be taken to get this issue ready for a second look. Work on solutions, it's more productive than bickering and insulting the developers (who volunteer their time).
