Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 17024 - emerge -uUD fails due to masked packages (nvidia)
Summary: emerge -uUD fails due to masked packages (nvidia)
Status: RESOLVED DUPLICATE of bug 13616
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Nicholas Jones (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-07 08:07 UTC by Peter Beekman
Modified: 2011-10-30 22:21 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Beekman 2003-03-07 08:07:54 UTC
If this should have been classified as an ebuilds bug, sorry...

Have tried:
beekster01 root # emerge -puUD world

These are the packages that I would merge, in order:

Calculating world dependencies \
!!! all ebuilds that could satisfy "~media-video/nvidia-kernel-1.0.4191" have
been masked.
!!!    (dependency required by "media-video/nvidia-glx-1.0.4191-r1" [ebuild])

As far as I can tell, I have the latest of nvidia-kernel and nvidia-glx
installed. See the "emerge -pC" commands below.

beekster01 root # emerge -pC nvidia-kernel

>>> These are the packages that I would unmerge:

 media-video/nvidia-kernel
    selected: 1.0.4191-r2
   protected: none
     omitted: none

>>> Packages in red are slated for removal.
>>> Packages in green will not be removed.

beekster01 root # emerge -pC nvidia-glx

>>> These are the packages that I would unmerge:

 media-video/nvidia-glx
    selected: 1.0.4191-r1
   protected: none
     omitted: none

>>> Packages in red are slated for removal.
>>> Packages in green will not be removed.

Now I find the failure to be incorrect as I have the latest (of these) packages
installed on my system.  They were installed with the ACCEPT_KEYWORDS='~x86'
set, and I thought the -uU would allow updates to proceed normally.

I understand that updating these packages would require the use again of the
ACCEPT_KEYWORDS='~x86' setting, but not that it would break updates (even
Deep/-D) ones after that that did not have that setting made.

ie -U should override -D, or be considered after it... in this situation.

I searched, if this is a dupe, 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




beekster01 root # emerge info
Portage 2.0.47-r8 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r2)
=================================================================
System uname: 2.4.19-gentoo-r10 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz
GENTOO_MIRRORS="ftp://mirror.aarnet.edu.au/pub/gentoo
http://gentoo.oregonstate.edu/
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config
/usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config
/usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY=""
USE="x86 oss 3dnow apm avi crypt cups encode gif gpm jpeg gnome libg++ libwww
mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv
zlib gtkhtml alsa gdbm berkdb slang readline arts bonobo svga java guile X sdl
tcpd pam ssl perl python esd imlib oggvorbis gtk qt kde motif opengl cdr"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -mmmx -msse -msse2 -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -mmmx -msse -msse2 -fomit-frame-pointer"
ACCEPT_KEYWORDS="x86"
MAKEOPTS="-j2"
AUTOCLEAN="yes"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
FEATURES="sandbox ccache"
Comment 1 Jay Pfeifer (RETIRED) gentoo-dev 2003-03-07 21:50:38 UTC
ok. this is not a bug with the nvidia ebuilds. this has to do with how portage works when one installs unstable (~arch) packages and then only accepts stable packages (arch) in their make.conf. there are plans to implement this feature in emerge (allowing it somehow to force using only ~arch dependencies of a ~arch package that is already on the system even though you are currently not accepting unstable packages). i'm sending this to carpaski & rexorient as i believe there may be a user submitted patch to help fix this (info from drobbins).
Comment 2 Peter Beekman 2003-11-27 22:25:09 UTC
This is both old, and no longer an issue for me.  Please close at your leaisure.
Comment 3 Marius Mauch (RETIRED) gentoo-dev 2003-11-28 02:17:41 UTC

*** This bug has been marked as a duplicate of 13616 ***