Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 14078 - emerge -u world fails due to single dependency check
Summary: emerge -u world fails due to single dependency check
Status: RESOLVED LATER
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 32427 (view as bug list)
Depends on: 34979
Blocks: 12768
  Show dependency tree
 
Reported: 2003-01-16 23:32 UTC by Joe
Modified: 2011-10-30 22:21 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge.diff (portage-robust.diff,6.37 KB, patch)
2003-01-18 16:42 UTC, J Robert Ray
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joe 2003-01-16 23:32:13 UTC
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...
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2003-01-17 08:58:58 UTC
robert, the gnupg needs to be sorted out

nick -- he has a point about portage stoppage, though that's probably a dupe bug
Comment 2 J Robert Ray 2003-01-17 09:42:48 UTC
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'?
Comment 3 J Robert Ray 2003-01-18 16:42:11 UTC
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.
Comment 4 J Robert Ray 2003-01-18 16:42:36 UTC
Created attachment 7423 [details, diff]
emerge.diff
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2003-09-21 08:40:41 UTC
Might confuse users, but I like it ;)
Comment 6 Martin Holzer (RETIRED) gentoo-dev 2003-11-02 11:00:22 UTC
*** Bug 32427 has been marked as a duplicate of this bug. ***
Comment 7 Martin Holzer (RETIRED) gentoo-dev 2003-12-04 03:32:59 UTC
i don't think this is really a good idea for all packages

see bug 34979 for details.
Comment 8 Marius Mauch (RETIRED) gentoo-dev 2003-12-04 06:47:38 UTC
I don't see any relation between these bugs Martin.
Comment 9 William Reeder 2004-10-25 11:40:07 UTC
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.
Comment 10 Samuel Penn 2005-04-29 09:57:33 UTC
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.
Comment 11 Alec Warner archtester gentoo-dev Security 2005-04-29 11:02:29 UTC
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.
Comment 12 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:25:07 UTC
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. ;)