/usr/portage/eclass/php.eclass Specifies that there must be a virtual/mta. mod_php and php both inherit from this class. My guess is that since there is an upgrade for your installed virtual/mta, it wants to upgrade it as well. I would suggest that you manually upgrade any other packages that php wants to upgrade, if any, and then do an
emerge --nodeps mod_php. 'course there may be a good reason it wants the latest postfix and the above command may cause your computer to explode. There, you've been warned. :) humbly, =C= * Cal Evans * http://www.christianperformer.com * Stay plugged into your audience * The measure of a programmer is not the number of lines of code he writes but the number of lines he does not have to write. * ----- Original Message ----- From: "Joel Osburn" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 13, 2003 12:11 PM Subject: RE: [gentoo-user] virtual/mta versus mod_php Brett Holcomb: Thanks for the suggestion. Checking the ebuild was one of the first things I did, but it only lists apache as a dependency, and is willing to use apache2 if that flag is set. I'm not clear where else dependencies are set. Quoth Marius Mauch [EMAIL PROTECTED]: > Ah, now I have an idea. I think the -u is the problem as it causes to > upgrade dependencies IIRC (and --deep is to upgrade dependencies of > dependencies). Because it sees that your installed version is not in the > tree it tries all the avaiable ebuilds in the tree in descending order, > but as you masked all available ebuilds it spits out the error. As I > said in one of my previous posts I think your mask needs to be updated > to allow the latest 1.x version of postfix to be installed (hava a look > at /usr/portage/net-mail/postfix). A little testing shows this to be true. If I try to emerge the mod_php-4.3.2.ebuild specifically, no dependency problems appear. If I emerge -u that ebuild, then the problem reappears. So that "-u" flag is causing the problem in that dependencies are attempting to be updated, too. If I mask mod_php, and then "emerge -pu world", I have no problems, but nothing listed depends on virtual/mta, so the problem doesn't have the opportunity to manifest. This seems to me to be a flaw in how checking for updates works; if a virtual slot is filled, (ie. virtual/mta in this case), then the dependency should be satisfied, regardless of whether or not that version is in the current tree. Rather, if that version is not in the current tree, and all versions in the current tree are masked, then the -u check should return "no updates available" instead of returning "all ebuilds that could satisfy "virtual/mta" have been masked." and dieing. Thanks for your insights! -Joel Osburn -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
