Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 79606 - Portage does not intelligently resolve blocks
Summary: Portage does not intelligently resolve blocks
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High normal with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 31098 53387 79759 81513 85519 86652 88479 89233 91153 91341 97422 113062 116104 116651 116671 116758 116865 116933 116938 118211 119169 123469 126014 129569 132529 134414 135343 135431 136772 138041 138224 138697 139890 141083 146556 148418 149454 157193 (view as bug list)
Depends on:
Blocks: 155723 147007
  Show dependency tree
 
Reported: 2005-01-26 10:16 UTC by Kevin Parent
Modified: 2009-03-12 22:07 UTC (History)
43 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 Kevin Parent 2005-01-26 10:16:35 UTC
Seems like I can't upgrade nvidia-glx or opengl-update.  nvidia-glx-1.0.6629-r4 upgrade requires opengl-update-2.1_pre3, which is blocked by the "NOT" installed xorg-x1l-6.8.0-r4!!

*  x11-base/xorg-x11
      Latest version available: 6.8.0-r3
      Latest version installed: 6.8.0-r3
      Size of downloaded files: 72,166 kB



Reproducible: Always
Steps to Reproduce:
1. "emerge sync" then "emerge -uDpv"
2. echo "x11-base/opengl-update ~amd64" >> /etc/portage/package.keywords and run "emerge -uDpv world" again....
3. Edited /etc/portage/package keywords, removing xll-base/opengl-update and changed media-video/nvidia-glx ~amd64 to =media-video/nvidia-glx-1.0.6629-r3 ~amd64 because nvidia-glx-1.0.6629-r4 requires opengl-update-2.1_pre3, which is blocked by the non-existent xorg-x11-6.8.0-r4.  I figure I'll just keep my current configuration.  Run "emerge -uDpv world" again....
Actual Results:  
1.
Calculating world dependencies /
!!! All ebuilds that could satisfy ">=x11-base/opengl-update-2.1_pre1" have been
masked.
!!! One of the following masked packages is required to complete your request:
- x11-base/opengl-update-2.1_pre3 (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.6629-r4" [ebuild])


!!! Problem with ebuild media-video/nvidia-settings-1.0.6629
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

2.
Calculating world dependencies ...done!
[blocks B     ] <x11-base/xorg-x11-6.8.0-r4 (from pkg
x11-base/opengl-update-2.1_pre3)
[ebuild     U ] x11-base/opengl-update-2.1_pre3 [1.8.2] 0 kB
[ebuild     U ] dev-perl/DBI-1.38-r1 [1.38] 0 kB
[ebuild     U ] media-video/nvidia-kernel-1.0.6629-r3 [1.0.6629-r2] 0 kB
[ebuild     U ] media-video/nvidia-glx-1.0.6629-r4 [1.0.6629-r3] 0 kB

Total size of downloads: 0 kB

3.
Calculating world dependencies ...done!
[ebuild     U ] dev-perl/DBI-1.38-r1 [1.38] 0 kB
[ebuild     U ] media-video/nvidia-kernel-1.0.6629-r3 [1.0.6629-r2] 0 kB
[ebuild     UD] media-video/nvidia-glx-1.0.6629-r1 [1.0.6629-r3] -multilib 0 kB

Total size of downloads: 0 kB


Expected Results:  
Allow me to either upgrade nvidia-glx-1.0.6629-r4 and opengl-update-2.1_pre3 or
allow me to use /etc/portage/keyword files to keep current config.

I have no problems with X or nvidia drivers, why should I have to downgrade
nvidia-glx-1.0.6629-r1 from r3?  Looks like r3 was removed from the Portage
tree, so even if I use "=media-video/nvidia-glx-1.0.6629-r3 ~amd64" in
package.kewords it won't keep nvidia-glx from being downgraded from r3 to r1.

Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3,
glibc-2.3.4.20040808-r1, 2.6.10-ck5
x86_64)=================================================================
System uname: 2.6.10-ck5 x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4 [2.3.4 (#1, Dec  2 2004, 22:22:12)]
dev-lang/python:     2.3.4
sys-devel/autoconf:  2.59-r5
sys-devel/automake:  1.8.5-r1
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.2-r7
virtual/os-headers:  2.6.8.1-r1, 2.6.8.1-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://ftp.du.se/pub/os/gentoo http://gentoo.binarycompass.org
http://gentoo.chem.wisc.edu/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="amd64 X alsa apache2 berkdb bitmap-fonts cdr crypt cups dga evo f77 fam
font-server foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imap imlib
ipv6 irda irmc java jp2 jpeg ldap libwww lzw lzw-tiff mbox mozilla multilib
mysql ncurses nls nptl oav offensive oggvorbis opengl pam pcre pda pdf pdflib
perl png posix ppds python readline samba sdl slang ssl tcltk tcpd tiff truetype
truetype-fonts type1-fonts usb userlocales xml xml2 xmms xpm xrandr xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LDFLAGS
Comment 1 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-26 11:41:30 UTC
No, you missed the 'less than' symbol in front of xorg -r4. It's blocked by everything LESS THAN 6.8.0-r4 (which includes -r3). So you need to upgrade your xorg to upgrade opengl-update.
Comment 2 Scott Carr 2005-02-12 11:48:44 UTC
I have seen this "problem" as well.  What is being stated is that the opengl-update files needs a later version of xorg-x11, but it is not installing the latest version of xorg-x11 _before_ it is trying to install opengl-update, so portage is saying a newer version of xorg-x11.  That is what is blocking the upgrade.

Why opengl-update doesn't try to install the newer version of xorg-x11 before it updates itself is problably something to do about order of dependancies.

To fix this problem, emerge the updated version of xorg-x11 before trying an emerge -u world.  

I noticed this on two computers I have here.
Comment 3 Rick Harris 2005-02-12 22:02:26 UTC
I too was hit with this cyclic dependancy bug.
The workaround was to first install xorg without opengl (which also means no xv), this will get your xorg-x11 version up past the 6.8.0-r4 version blocker, enabling xorg to be installed again with the +opengl +xv flags enabled, thus also updating opengl-update:

USE="-xv -opengl" emerge xorg-x11 && USE="xv opengl" emerge xorg-x11

Takes forever, but it works.
Comment 4 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-13 02:54:14 UTC
Actually, the REAL workaround would be to not use -uvD world.  just do 'emerge -v xorg-x11 && emerge -uvD world'  Assuming you have one of the opengl-update-2.0's installed, that sould work fine.
Comment 5 Jeremy Huddleston (RETIRED) gentoo-dev 2005-04-10 14:08:25 UTC
*** Bug 85519 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Huddleston (RETIRED) gentoo-dev 2005-04-10 14:08:50 UTC
*** Bug 79759 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Huddleston (RETIRED) gentoo-dev 2005-04-10 14:10:56 UTC
*** Bug 86652 has been marked as a duplicate of this bug. ***
Comment 8 Jeremy Huddleston (RETIRED) gentoo-dev 2005-04-10 14:11:29 UTC
*** Bug 88479 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Huddleston (RETIRED) gentoo-dev 2005-04-10 14:12:45 UTC
reopen so it can be assigned to dev-portage to look at for fixing
Comment 10 Carsten Lohrke (RETIRED) gentoo-dev 2005-04-15 16:24:40 UTC
*** Bug 89233 has been marked as a duplicate of this bug. ***
Comment 11 Jeremy Huddleston (RETIRED) gentoo-dev 2005-04-26 13:19:51 UTC
*** Bug 81513 has been marked as a duplicate of this bug. ***
Comment 12 nobody 2005-04-26 15:52:37 UTC
should be extend to all platform i think, not amd only related one (at least fail on x86 too)
Comment 13 Martin von Gagern 2005-04-28 10:20:47 UTC
Another one of those circular dependencies:

I have installed:
x11-libs/openmotif-2.1.30-r6 *
x11-libs/motif-config-0.8 *
x11-libs/openmotif-2.2.3-r6 *

Emerge -ua world yields this circular dependency:
[blocks B     ] <x11-libs/openmotif-2.1.30-r13
                (is blocking x11-libs/motif-config-0.9)
[blocks B     ] =x11-libs/openmotif-2.2.3-r6
                (is blocking x11-libs/motif-config-0.9)
[ebuild     U ] x11-libs/motif-config-0.9 [0.8] 
[ebuild     U ] sys-devel/gettext-0.14.4 [0.14.2] 
[ebuild     U ] sys-devel/gnuconfig-20050324 [20050223] 
[ebuild     U ] sys-libs/glibc-2.3.5 [2.3.4.20050125-r1] 
[ebuild     U ] x11-libs/openmotif-2.2.3-r7 [2.2.3-r6] 
Comment 14 Donnie Berkholz (RETIRED) gentoo-dev 2005-04-28 13:28:53 UTC
You can unmerge all your openmotif's, merge motif-config and remerge openmotif.
Comment 15 Jason Stubbs (RETIRED) gentoo-dev 2005-05-02 04:48:16 UTC
*** Bug 91153 has been marked as a duplicate of this bug. ***
Comment 16 Jason Stubbs (RETIRED) gentoo-dev 2005-05-02 04:48:40 UTC
*** Bug 53387 has been marked as a duplicate of this bug. ***
Comment 17 Carsten Lohrke (RETIRED) gentoo-dev 2005-05-03 14:30:49 UTC
*** Bug 91341 has been marked as a duplicate of this bug. ***
Comment 18 Jason Rhinelander 2005-05-05 15:47:59 UTC
Another occurance between gnome-themes and gtk-engines:

emerge -pv gtk-engines
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[blocks B     ] <=x11-themes/gnome-themes-2.8.2 (is blocking x11-themes/gtk-engines-2.6.2)
[ebuild     U ] x11-themes/gtk-engines-2.6.2 [2.2.0] 433 kB

Comment 19 Prof. Jonathan King 2005-06-08 19:53:46 UTC
Is this thread
http://forums.gentoo.org/viewtopic-p-2480090.html#2480090
a (more recent) example of circular dependency?
Comment 20 Jason Stubbs (RETIRED) gentoo-dev 2005-06-09 04:16:58 UTC
(In reply to comment #18)  
> Another occurance between gnome-themes and gtk-engines:  
>   
> emerge -pv gtk-engines  
> These are the packages that I would merge, in order:  
>   
> Calculating dependencies ...done!  
> [blocks B     ] <=x11-themes/gnome-themes-2.8.2 (is blocking  
x11-themes/gtk-engines-2.6.2)  
> [ebuild     U ] x11-themes/gtk-engines-2.6.2 [2.2.0] 433 kB  
  
There is nothing portage can do to resolve this. The block is 100% correct.  
  
  
 (In reply to comment #19) 
> Is this thread 
> http://forums.gentoo.org/viewtopic-p-2480090.html#2480090 
> a (more recent) example of circular dependency? 
 
I don't see exactly what you are asking. 
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2005-06-29 15:03:29 UTC
*** Bug 97422 has been marked as a duplicate of this bug. ***
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2005-08-14 06:02:16 UTC
*** Bug 102479 has been marked as a duplicate of this bug. ***
Comment 23 Jakub Moc (RETIRED) gentoo-dev 2005-09-18 16:21:52 UTC
*** Bug 106420 has been marked as a duplicate of this bug. ***
Comment 24 Pablo Yanez Trujillo 2005-09-18 16:31:49 UTC
I found new block problems

[blocks B     ] >=net-www/apache-2.0.54-r30 (is blocking dev-php/mod_php-4.4.0)
[ebuild  N    ] dev-libs/apr-0.9.6-r3
[ebuild  N    ] net-www/gentoo-webroot-default-0.2
[ebuild  N    ] dev-libs/apr-util-0.9.6-r2
[ebuild     U ] net-www/apache-2.0.54-r31

installed is net-www/apache-2.0.54-r15.

It seems that mod_php is blocking apache-2.0.54-r30 but apache-2.0.54-r31 wants 
to be installed. I took a look on mod_php-4.4.0.ebuild and found

DEPEND_EXTRA=">=net-www/apache-1.3.26-r2
              apache2? ( >=net-www/apache-2.0.43-r1
                        !>=net-www/apache-2.0.54-r30 )"

but on net-www/apache-2.0.54-r31.ebuild I found

KEYWORDS="... x86"

and I think this is a problem because when you try to upgrade (my current apache 
is apache-2.0.54-r15) it will try to install apache-2.0.54-r31 but >=apache-2.0.
54-r30 is blocked by mod_php ...
Comment 25 Pablo Yanez Trujillo 2005-09-19 01:29:09 UTC
I think there is a problem with mod_php again :)

mod_php-4.4.0-r1.ebuild:
DEPEND_EXTRA=">=net-www/apache-1.3.33-r10
              apache2? ( >=net-www/apache-2.0.54-r30 )"

this would install net-www/apache-2.0.54-r31 (since r30 is masked by ~arch)

but mod_php-4.4.0-r2.ebuild has:
KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc x86"
DEPEND_EXTRA=">=net-www/apache-1.3.26-r2
              apache2? ( >=net-www/apache-2.0.43-r1
                        !>=net-www/apache-2.0.54-r30 )"

and it blocks apache-2.0.54-r31 again and mod_php.4.4.0 still blocks >=apache-2.
0.54-r30 and so you get an error with emerge -uD world.
Comment 26 Paul de Vrieze (RETIRED) gentoo-dev 2005-09-19 03:54:40 UTC
I guess you were just caught right in the middle of the big apache2
stabilization. The apache 2 setup has changed in a kindof incompatible way from
ebuild perspective. Yesterday all packages supporting the new setup were
stabilized. I guess that your sync got the allready stabilized apache 2, but
didn't find a stabilized mod_php supporting the new apache2 yet. The
dependencies on the packages prevent broken installs, but do so by blocking. If
you sync again, everything should be solved. For more info you might want to
look at bug #76457
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2005-10-22 08:54:24 UTC
*** Bug 110088 has been marked as a duplicate of this bug. ***
Comment 28 Jakub Moc (RETIRED) gentoo-dev 2005-10-25 15:06:14 UTC
*** Bug 31098 has been marked as a duplicate of this bug. ***
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2005-11-20 01:42:19 UTC
*** Bug 113062 has been marked as a duplicate of this bug. ***
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2005-12-19 15:51:46 UTC
*** Bug 116104 has been marked as a duplicate of this bug. ***
Comment 31 Jakub Moc (RETIRED) gentoo-dev 2005-12-24 16:25:43 UTC
*** Bug 116651 has been marked as a duplicate of this bug. ***
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2005-12-25 03:41:47 UTC
*** Bug 116671 has been marked as a duplicate of this bug. ***
Comment 33 Jakub Moc (RETIRED) gentoo-dev 2005-12-26 03:49:47 UTC
*** Bug 116758 has been marked as a duplicate of this bug. ***
Comment 34 Carsten Lohrke (RETIRED) gentoo-dev 2005-12-27 06:01:58 UTC
*** Bug 116865 has been marked as a duplicate of this bug. ***
Comment 35 Zac Medico gentoo-dev 2005-12-27 18:47:30 UTC
*** Bug 116938 has been marked as a duplicate of this bug. ***
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2005-12-29 16:01:39 UTC
*** Bug 116933 has been marked as a duplicate of this bug. ***
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2006-01-07 02:42:38 UTC
*** Bug 118141 has been marked as a duplicate of this bug. ***
Comment 38 Alec Warner (RETIRED) archtester gentoo-dev Security 2006-01-07 11:41:31 UTC
*** Bug 118211 has been marked as a duplicate of this bug. ***
Comment 39 DEMAINE Benoît-Pierre, aka DoubleHP 2006-01-09 03:51:58 UTC
poppler vs xpdf was big mess in december 2005 http://bugs.gentoo.org/show_bug.cgi?id=116933 ; emerge -Cav foobar && emerge -va foobar seems to work for some people.
Comment 40 Jakub Moc (RETIRED) gentoo-dev 2006-01-16 01:10:30 UTC
*** Bug 119169 has been marked as a duplicate of this bug. ***
Comment 41 Marius Mauch (RETIRED) gentoo-dev 2006-02-20 02:31:54 UTC
*** Bug 123469 has been marked as a duplicate of this bug. ***
Comment 42 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-13 01:55:10 UTC
*** Bug 126014 has been marked as a duplicate of this bug. ***
Comment 43 Jakub Moc (RETIRED) gentoo-dev 2006-04-11 02:37:44 UTC
*** Bug 129569 has been marked as a duplicate of this bug. ***
Comment 44 Jakub Moc (RETIRED) gentoo-dev 2006-05-06 23:33:35 UTC
*** Bug 132529 has been marked as a duplicate of this bug. ***
Comment 45 Jakub Moc (RETIRED) gentoo-dev 2006-05-26 06:29:58 UTC
*** Bug 134414 has been marked as a duplicate of this bug. ***
Comment 46 Alec Warner (RETIRED) archtester gentoo-dev Security 2006-06-02 21:22:27 UTC
*** Bug 135343 has been marked as a duplicate of this bug. ***
Comment 47 Jakub Moc (RETIRED) gentoo-dev 2006-06-14 06:18:38 UTC
*** Bug 136772 has been marked as a duplicate of this bug. ***
Comment 48 Jakub Moc (RETIRED) gentoo-dev 2006-06-16 05:28:13 UTC
*** Bug 136638 has been marked as a duplicate of this bug. ***
Comment 49 Jakub Moc (RETIRED) gentoo-dev 2006-06-26 06:19:10 UTC
*** Bug 138041 has been marked as a duplicate of this bug. ***
Comment 50 Jakub Moc (RETIRED) gentoo-dev 2006-06-27 11:24:07 UTC
*** Bug 138224 has been marked as a duplicate of this bug. ***
Comment 51 Aaron Peterson 2006-06-29 00:20:32 UTC
Is this going to require more data being put into ebuilds?

I've always been a fan of having an interactive version of portage if it basically comes down to having the user make the choice of what to do.

it doesn't have to be a real interactive version.. just so long as the ebuild tells the user what to do next. (showing up on the screen for a split second while it scrolls by doesn't count).. and it's as easy as hitting a key, or adding another "feature" to the features list that says, go ahead and nuke old versions it's not a running service.

Does the new java system contain any scripts that would be usefull for situations like this?
Comment 52 Jakub Moc (RETIRED) gentoo-dev 2006-07-01 06:11:57 UTC
*** Bug 138697 has been marked as a duplicate of this bug. ***
Comment 53 Joe Wells 2006-07-01 08:04:43 UTC
(In reply to comment #52)
> *** Bug 138697 has been marked as a duplicate of this bug. ***

From reading through the comments on this bug, it seems to me that the
situation in bug 138697 is a bit different from the situations
described above.  In bug 138697, the cycle is like this:

  C/Y-1 is installed and does not depend on C/X

  no version of C/X is installed

  C/X-1.ebuild contains DEPEND="!<C/Y-1"

  C/Y-2.ebuild contains RDEPEND="C/X"

In this case, because one edge of the cycle is through an RDEPEND
instead of all edges being through DEPENDs, it should be safe for
emerge to install C/Y-2 before C/X-1, as long as they are both done in
the same run.  This would allow things to proceed automatically.

Obviously, there is a risk if installing C/Y-2 succeeds and installing
C/X-1 fails.  If this happens, the user would need to be warned that
an RDEPEND of C/Y-2 was not successfully installed and that they
should consider reverting.

Comments?
Comment 54 Jakub Moc (RETIRED) gentoo-dev 2006-07-10 08:28:43 UTC
*** Bug 139890 has been marked as a duplicate of this bug. ***
Comment 55 Robert Golding 2006-07-10 10:55:40 UTC
(In reply to comment #54)
> *** Bug 139890 has been marked as a duplicate of this bug. ***
> 
My bug (139890) is NOT the same as this one at all!  It is just that the system that pulls in nvidia does not differentiate the three positions of the drivers, and that causes a block

i.e. this section of the xorg-x11-7.0-r1.ebuild code isn't working properly
//-------->
video_cards_nvidia? ( || ( media-video/nvidia-glx
			x11-drivers/nvidia-drivers
			x11-drivers/nvidia-legacy-drivers ) )
//------>

Problem is, I don't know how to fix it, don't know how to code :-)
Comment 56 Jakub Moc (RETIRED) gentoo-dev 2006-07-10 11:09:55 UTC
*** Bug 139890 has been marked as a duplicate of this bug. ***
Comment 57 DEMAINE Benoît-Pierre, aka DoubleHP 2006-07-10 11:11:26 UTC
(In reply to comment #55)
> i.e. this section of the xorg-x11-7.0-r1.ebuild code isn't working properly
> //-------->
> video_cards_nvidia? ( || ( media-video/nvidia-glx
>                         x11-drivers/nvidia-drivers
>                         x11-drivers/nvidia-legacy-drivers ) )
> //------>

and bits of code from ebuilds are interpreted by ? ... emerge that relies on portage rules. I will not acknoledghe  whether your bug is really a dup or not, because I am not to take time to read your bug; any way, I am not a maintainer, and I have no right over bugs; still, from what you say, your comment still make me think that your bug *may* be a dup of this one :)

If I was a maint, your agumentatin would not make me change my mind.

Fram what you say, your problem depends on the rule-set of portage !!!
Comment 58 David Carlos Manuelda 2006-07-11 05:00:27 UTC
And how about to add a feature to portage to make the user select what to do? (update all but blockers and its relevant packages, some way to avoid blockers merging or unmerging some packages, etc...)
Comment 59 Aaron Peterson 2006-07-11 16:26:29 UTC
Re comment 58

Yes! We should be able to have xorg 7.1 be marked stable.. but have it not be merged if our use flags require something that is not compatible with it.


We should at least be able to upgrade all other packages that are not affected...

But these are features that Debian has had forever... (implemented interactively)

and I don't know why the heck we cant have an interactive option for portage... but we can still do what we need without interactivity




Comment 60 DEMAINE Benoît-Pierre, aka DoubleHP 2006-07-11 16:47:40 UTC
When you have 10 to 500 debian box, you want auto-apt, or apt-cron.

Portage is already nice on a single box; why the hell would any one make portage intercative when it will only make things more and more difficult on clusters ? or maybe not even clusters, but just LAN maintainance !!!

No, I love portage sp
Comment 61 DEMAINE Benoît-Pierre, aka DoubleHP 2006-07-11 16:47:40 UTC
When you have 10 to 500 debian box, you want auto-apt, or apt-cron.

Portage is already nice on a single box; why the hell would any one make portage intercative when it will only make things more and more difficult on clusters ? or maybe not even clusters, but just LAN maintainance !!!

No, I love portage spécially because it is higly scriptable; if any trouble occured, I het a non null value, I check emerge logs to see last ebuild that failed, then I can catch failure log in /var/log/portage/ebuild-name. All that could be easily automated if I wanted to.

NO i dont want interactive portage. And making interactivity possible, even if just optionnal, would make whe whole system conception more complex, thus potentially buggy !!!
Comment 62 Aaron Peterson 2006-07-12 11:35:31 UTC
NO, I'm not trying to start an interactive portage war here.  Debian has an option to make it non-interactive too.. so if you're running gentoo only because of that you're silly.

There is no correct way to resolve the blocks.  It is a user preference. Fortuantely there are just a few ways to do it.

We can create rulesets that approximate what different types of users would want. 

I would notice a block, the block would have a list of rulesets, I would edit my make.conf to include the ruleset feature that I wanted.

I would choose the ruleset that would keep my xorg-x11 from being merged because I need the nvidia driver.

This ruleset might include key package lists that need to be kept stable, or at bleeding edge as possible without breaking stable ones

-AP
Comment 63 DEMAINE Benoît-Pierre, aka DoubleHP 2006-07-12 11:58:38 UTC
no, I did not move to GEntoo for non-interactivity, and that is not either the reason why I keep it :) Still, I beleave that trying to add 'interactivity possibility' to portage would make it more complex, thus, potentially buggy.

When I have blocking problems, I tweek (tweak ?) /etc/portage/* a way that emerge can do what I want. Sometimes mask, sometime add use-flags for particular ebuilds and so on.

When I was too lame to solve the blocking problem of Xorg-1.0*, I just blocked it :) thus kept using 0.6* for the time I was lame, but was still able to emerge other things. On a boring day, I removed the blocking line, and solved manually the problem an apropriate way.

I mean, what ever my problem is, I solve it most of the time by editing /etc/portage/* , then I eventually complain in this BTS, and a few days later, I esync, and undo the changes I did to my /etc.
Comment 64 Aaron Peterson 2006-07-12 12:23:35 UTC
I've ended up having funky bugs because of editing my /etc/portage stuff.

There are relatively few common configurations for gentoo... and lots of goofed up configurations that are trying to do stuff that somebody else has done better.

We should be able to tweak stuff all we want.. but we shouldn't have to tweak stuff just to get it to work... even in ~    ~ should be where we make it all work before it goes to stable.  (so ~ can break somemtimes, but a sync later should fix it)
Comment 65 Peter Thomassen 2006-07-12 12:26:17 UTC
In reply to comment #61:
Couldn't this also be done based on already present configuration variables? There is VIDEO_CARDS, which could be checked for nvidia. If nvidia is present, xorg-server could automatically be masked (i.e. let KEYWORDS depend on VIDEO_CARDS).

(Another, maybe excrescent way is to introduce an USE flag to let KEYWORDS depend on.)

Are there technichal reasons against this?
Peter
Comment 66 Jakub Moc (RETIRED) gentoo-dev 2006-07-19 14:52:36 UTC
*** Bug 141083 has been marked as a duplicate of this bug. ***
Comment 67 Zac Medico gentoo-dev 2006-07-25 20:08:41 UTC
*** Bug 135431 has been marked as a duplicate of this bug. ***
Comment 68 Adam Carheden 2006-08-30 12:11:44 UTC
(In reply to comment #66)
> *** Bug 135431 has been marked as a duplicate of this bug. ***
> 

I just wanted to post what i think is another example of this bug that might help resolution.


I have a clean gentoo 2006.0 AMD64 install (I'm still booted into the CD) with the 20060828 snapshot. I'm running a script that will install all of my packages, including nxserver-freenx, nx-x11-bin, and others. ">x11-base/xorg-x11-6.9" is masked in /etc/portage/package.mask because nxserver is reported not to work with X7 on AMD64. The first time I ran it (with the -pvt emerge flags and xorg-x11 emerged only as a dependency), I got a bunch error messages like this:

	[blocks B] x11-*/*' (is blocking x11-base/xorg-x11-6.8.2-r8)

If I added x11-base/xorg-x11 as the first package to emerge, I got no blocked packages and xorg-x11-6.8.2-r8 was listed.

Seems like portage should pick correct xorg-x11 for me rather than whining about blocks.
Comment 69 nobody 2006-08-30 14:55:52 UTC
Well, i think that bug was originally because
package A need package B
package B is blocked by package A (or A block B)

Witch was the case with xorg & opengl-update... I don't think it's to flame out blockers.

the question is: is there anyone working on that? seems days that my name was put on that list & nothing change yet
Comment 70 Jakub Moc (RETIRED) gentoo-dev 2006-09-06 07:47:08 UTC
*** Bug 146556 has been marked as a duplicate of this bug. ***
Comment 71 Jakub Moc (RETIRED) gentoo-dev 2006-09-20 13:59:56 UTC
*** Bug 148418 has been marked as a duplicate of this bug. ***
Comment 72 Zac Medico gentoo-dev 2006-09-22 19:28:29 UTC
This bug is solved by the patches from bug 147766 and bug 16365 which have been released in 2.1.2_pre1-r1.
Comment 73 Jakub Moc (RETIRED) gentoo-dev 2006-09-28 14:55:20 UTC
*** Bug 149454 has been marked as a duplicate of this bug. ***
Comment 74 Jakub Moc (RETIRED) gentoo-dev 2006-12-05 02:18:24 UTC
*** Bug 157193 has been marked as a duplicate of this bug. ***
Comment 75 Martin Walch 2009-03-12 21:20:16 UTC
Sorry if this is wrong here. It is just a guess where to put it:

Currently, x11-base/xorg-server-1.4.2[input_devices_evdev] pdepends on >=x11-drivers/xf86-input-evdev-1.1.1.

x11-drivers/xf86-input-evdev-2.2.0-r1 rdepends on >=x11-base/xorg-server-1.5.3.

This leads to xorg-server-1.4.2 depending indirectly upon xorg-server-1.5.3, although there is a way to resolve this. However, the problem to find a proper solution whenever there is one, is probably NP-complete (not sure, did not investigate this in detail). So this is probably no way to go.

Maybe there should be a guideline that makes sure that above problem can not occurr? (maybe depend only on versions of evdev that will work. Or maybe block >=x11-drivers/xf86-input-evdev-2.1.0 in <x11-base/xorg-server-1.4.99 would help. Anyway, this does not seem to be possible as of Portage 2.1.6.7, because any blocker will be ignored, if there is some sort of dependency on the blocked package.)