Firefox 10.0.7 needs libffi 3.0.9 or higher. But it depends only on virtual/libffi. The current virtual/libffi depends on >=dev-libs/libffi-3.0.10. So if you've never installed virtual/libffi, everything works. But I had an older copy of virtual/libffi already installed, which simply depended on dev-libs/libffi. And I had dev-libs/libffi-3.0.8 installed. Since both my old installed virtual/libffi and the current virtual/libffi are version 0, Paludis saw no reason to reinstall virtual/libffi (which would force dev-libs/libffi to be upgraded). Instead, it tried to build Firefox with dev-libs/libffi-3.0.8, and configure quit with an error. Reproducible: Always Steps to Reproduce: 1. Install an old copy of virtual/libffi and dev-libs/libffi-3.0.8 2. Put the current virtual/libffi back in /usr/portage 3. Attempt to install www-client/firefox-10.0.7 Actual Results: Firefox's configure complained about not having libffi >=3.0.9 Expected Results: dev-libs/libffi-3.0.8 should have been upgraded to dev-libs/libffi-3.0.11 before attempting to build Firefox.
It looks like this was fixed already. # ChangeLog for virtual/libffi # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/virtual/libffi/ChangeLog,v 1.28 2012/06/14 23:13:33 ssuominen Exp $ 14 Jun 2012; Samuli Suominen <ssuominen@gentoo.org> libffi-0.ebuild: Raise dev-libs/libffi dependency to >= 3.0.10.
(In reply to comment #1) > It looks like this was fixed already. > > # ChangeLog for virtual/libffi > # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 > # $Header: /var/cvsroot/gentoo-x86/virtual/libffi/ChangeLog,v 1.28 > 2012/06/14 23:13:33 ssuominen Exp $ > > 14 Jun 2012; Samuli Suominen <ssuominen@gentoo.org> libffi-0.ebuild: > Raise dev-libs/libffi dependency to >= 3.0.10. You missed my point. That change *did not* increment the version number of virtual/libffi. Therefore, if you already had the previous version of virtual/libffi installed (which depended only on *any* version of dev-libs/libffi), Paludis won't find any reason to reinstall virtual/libffi (which would bring in the new minimum version dependency). The version number didn't change, so it's not considered an upgrade. You have to manually force it to reinstall virtual/libffi, which you won't know to do until some compilation dies from trying to use the old libffi. The solution here would be to rename libffi-0.ebuild to libffi-3.0.10.ebuild (since that's the minimum version it's depending on) and change firefox-10.0.7.ebuild (and any other ebuilds that need a minimum version of libffi) to depend on >=virtual/libffi-3.0.9 (or whatever version they require). If you only renamed libffi-0.ebuild, it would at least indicate it's an upgrade, but it wouldn't stop the old virtual/libffi from satisfying dependencies for ebuilds that really need the new virtual/libffi.
In other words, that change didn't fix the problem, it *created* the problem.
The virtual should have been incremented, I do not see why this is assigned to mozilla as everyone wants to use the virtual rather then hardcode the dep to begin with.
The virtual is there since historically it has happened before, first libffi went unmaintained, then the actual package for it got outdated, switched to gcc's libffi, then it got unmaintained in Gentoo... It's an one-man effort to maintain the separate copy, and two-man job to merge the diff's between gcc and back. I don't have any strong opinion on having the virtual or not, but that is what toolchain lead insisted at the time. You are welcome to reconvince him if you wish. Meanwhile doing that... I've added the versioned virtuals... http://sources.gentoo.org/viewvc.cgi/gentoo-x86/virtual/libffi/libffi-3.0.10.ebuild?rev=1.1&content-type=text/plain http://sources.gentoo.org/viewvc.cgi/gentoo-x86/virtual/libffi/libffi-3.0.11.ebuild?rev=1.1&content-type=text/plain So unCCing myself -> Rest is for mozilla@
As latest stable is now fixed closing. We will update ~arch when appropriate.
