I've been trying to update world for quite some time now to no avail. When I type emerge -up world or emerge -up evolution a mozilla dependency >=app-crypt/gnupg-1.2.1 fails and claims that all builds to satisfy >=app-crypt/gnupg-1.2.1 are masked. I have manually and successfully emerged gnupg-1.2.1 as well as gnupg-1.2.1-r1 to no avail and continue to receive the same error regardless of which version happens to be installed. An emerge -s gnupg shows that gnupg-1.2.1 is indeed installed. grep -i gnupg /usr/portage/profiles/package.mask does not yield any results, so I am unable to explicitly unmask gnupg here by editing the file, as has been suggested to me in the #gentoo irc channel. So I have a few questions: 1) What may be the cause of the problem? 2) How do I fix it? AND 3) Why does emerge -up --deep world fail instead of continuing and successfully upgrading those packages not affected by the phantom masked gnupg so I can at least have a mostly up-to-date system? 4) Flamebait, but relevant: Why would anyone want to use Gentoo when a package-specific error prevents an upgrade of the rest of your system? Related: http://bugs.gentoo.org/show_bug.cgi?id=13104 http://forums.gentoo.org/viewtopic.php?t=30348 http://forums.gentoo.org/viewtopic.php?t=29278 http://forums.gentoo.org/viewtopic.php?t=29278&postdays=0&postorder=asc&start=25 That's pretty much the problem/issue... I want it to be easy to update my system without having to dump 50 unstable packages on it...
robert, the gnupg needs to be sorted out nick -- he has a point about portage stoppage, though that's probably a dupe bug
gnupg-1.2.1-r1 was unmasked Dec 26, something here doesn't jibe. /usr/portage/app-crypt/gnupg/gnupg-1.2.1-r1.ebuild should contain: KEYWORDS="x86 ppc sparc ~alpha" Can you please paste the output of 'emerge info' and the entire output of 'emerge -up world'?
Okay, I have patched Portage (emerge) to address the larger issue. 1) If an uninstallable package is encountered, it does not terminate. Instead, all installable packages are processed as normal. 2) When an uninstallable package or dependency is encountered, increasingly older versions of the blocking package are considered until one is found where all deps can be reconciled. #2 in general makes #1 unnecessary. In my example case, I manually unmasked sylpheed-claws-0.8.8-r1, it depends on a version of gpgme that is masked. I also manually edited slypheed-claws-0.8.7 to make it depend on the same masked gpgme version. ------------------------------------------------------------------------------- geep root # emerge -up sylpheed-claws These are the packages that I would merge, in order: Calculating dependencies | !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.8-r1" [ebuild]) / !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.7" [ebuild]) ...done! [ebuild N ] net-mail/sylpheed-claws-0.8.6 ------------------------------------------------------------------------------- Above, an attempt to merge sylpheed-claws reports that both 0.8.8-r1 and 0.8.7 cannot be installed because of gpgme, and selects version 0.8.6 to be installed. This also works when looking for dependencies. I edited httptunnel (picked at random) to depend on sylpheed-claws: ------------------------------------------------------------------------------- geep root # emerge -up httptunnel These are the packages that I would merge, in order: Calculating dependencies / !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.8-r1" [ebuild]) - !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.7" [ebuild]) ...done! [ebuild N ] net-mail/sylpheed-claws-0.8.6 [ebuild N ] net-misc/httptunnel-3.0.5 ------------------------------------------------------------------------------- So same thing here, an earlier version of sylpheed-claws is picked. This works to any depth. Here I've made zlib-1.1.4 depend on a masked version of lynx, and gpgme-0.3.9 depend on >=zlib-1.1.4. (I also had to remove the zlib line from package.mask for this experiment.) ------------------------------------------------------------------------------- geep root # emerge -up httptunnel These are the packages that I would merge, in order: Calculating dependencies / !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.8-r1" [ebuild]) - !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.7" [ebuild]) - !!! all ebuilds that could satisfy "=net-www/lynx-2.8.4.1d" have been masked. !!! (dependency required by "sys-libs/zlib-1.1.4" [ebuild]) !!! all ebuilds that could satisfy ">=sys-libs/zlib-1.1.4" have been masked. !!! (dependency required by "app-crypt/gpgme-0.3.9" [ebuild]) / !!! all ebuilds that could satisfy "=net-www/lynx-2.8.4.1d" have been masked. !!! (dependency required by "sys-libs/zlib-1.1.4" [ebuild]) ...done! [ebuild N ] sys-libs/zlib-1.1.3-r3 [ebuild N ] app-crypt/gpgme-0.3.6-r1 [ebuild N ] net-mail/sylpheed-claws-0.8.6 [ebuild N ] net-misc/httptunnel-3.0.5 ------------------------------------------------------------------------------- It has to install an older version of sylpheed-claws, gpgme, and zlib to work everything out. You get the idea. Putting the zlib line back into package.mask, with my other changes, makes it impossible to install zlib. An attempt to install httptunnel plus other things won't abort anymore. Instead, what is still able to be installed will be: ------------------------------------------------------------------------------- geep root # emerge -p httptunnel adzapper These are the packages that I would merge, in order: Calculating dependencies | !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.8-r1" [ebuild]) / !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.3.10" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.7" [ebuild]) | !!! all ebuilds that could satisfy "=net-www/lynx-2.8.4.1d" have been masked. !!! (dependency required by "sys-libs/zlib-1.1.4" [ebuild]) !!! all ebuilds that could satisfy ">=sys-libs/zlib-1.1.4" have been masked. !!! (dependency required by "app-crypt/gpgme-0.3.9" [ebuild]) - !!! all ebuilds that could satisfy "=net-www/lynx-2.8.4.1d" have been masked. !!! (dependency required by "sys-libs/zlib-1.1.4" [ebuild]) !!! all ebuilds that could satisfy ">=sys-libs/zlib-1.1.3" have been masked. !!! (dependency required by "app-crypt/gpgme-0.3.6-r1" [ebuild]) !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.2.3" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.6" [ebuild]) \ !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.2.3" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.5" [ebuild]) | !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.2.3" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.3" [ebuild]) / !!! all ebuilds that could satisfy ">=app-crypt/gpgme-0.2.3" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.8.2" [ebuild]) !!! all ebuilds that could satisfy "net-mail/sylpheed-claws" have been masked. !!! (dependency required by "net-misc/httptunnel-3.0.5" [ebuild]) !!! all ebuilds that could satisfy "httptunnel" have been masked. ...done! [ebuild N ] net-www/squid-2.5.1-r1 [ebuild N ] net-www/adzapper-20030111 ------------------------------------------------------------------------------- I hope this patch can be accepted into Portage and get some more testing.
Created attachment 7423 [details, diff] emerge.diff
Might confuse users, but I like it ;)
*** Bug 32427 has been marked as a duplicate of this bug. ***
i don't think this is really a good idea for all packages see bug 34979 for details.
I don't see any relation between these bugs Martin.
I would like to highlight what I think is the real issue, and that is that an inability to resolve a dependency should not cause portage to exit and do nothing. Instead, portage should report the issue, but continue building the dependency tree for other packages so that other packages may be emerged. By the way, the new detail provided in this case by portage-2.0.51 is a very welcome thing. We just need to take the next step and make this a non-fatal error similar to the handling of blocking packages. I.e. the fact that one package is blocked does not prevent other packages from being emerged. Similarly, the fact that dependencies cannot be resolved for one package should not prevent other packages from being emerged.
On AMD64, but seems to be a similar problem. I have the following in package.keywords: >=media-video/nvidia-kernel-1.0.7174 ~amd64 >=media-video/nvidia-glx-1.0.7174-r1 ~amd64 When I tried to "emerge -p world" today it failed with: Calculating world dependencies - !!! All ebuilds that could satisfy ">=x11-base/opengl-update-2.2.0" have been masked. !!! One of the following masked packages is required to complete your request: - x11-base/opengl-update-2.2.1 (masked by: ~amd64 keyword) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. !!! (dependency required by "media-video/nvidia-glx-1.0.7174-r3" [ebuild]) With this error, the emerge failed completely and didn't attempt to look at anything else. Removing the two entries (or setting to '=' instead of '>=' would probably work) from package.keywords 'fixes' the problem, though it now wants to downgrade my drivers (they're working just fine for me thankyou very much). Presumably it wants to upgrade to the later masked driver, which has a new dependency (opengl-update) which is also masked, but which is not listed in my package.keywords (since the older masked driver had a dependency on a non-masked version of opengl-update). Using portage 2.0.51.19.
Samuel, this looks like correct behavior, the new drivers indeed have opengl-uppdate-2.2 as a dependency and portage will not emerge this for you unless you unmask it yourself. The "check on other packcages that don't depend on masked ones" is a complex issue and is in the plan for a future version. It requires a lot of refactoring however.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
