[This must be a dup but I couldn't find anything!] --update doesn't seem to do anything in these new portage versions. I do remember reading somewhere there was a change in behavior but I don't think it was supposed to be this drastic: Here is an example using 2.1.2-pre1-r1: # emerge -vup scipy These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-admin/eselect-blas-0.1 0 kB [ebuild N ] app-admin/eselect-cblas-0.1 0 kB [ebuild U ] sci-libs/blas-atlas-3.7.11-r1 [3.7.11] USE="-debug -doc" 1,990 kB [ebuild N ] app-admin/eselect-lapack-0.1 0 kB [ebuild U ] sci-libs/lapack-atlas-3.7.11-r1 [3.7.11] USE="-debug -doc -ifc" 4,934 kB [ebuild U ] dev-python/numpy-1.0_rc1 [1.0_beta2] USE="lapack" 1,094 kB [ebuild U ] sci-libs/scipy-0.5.1 [0.4.9] USE="fftw -debug" 4,043 kB and with 2.1.2-pre1-r2 (or r3) # emerge -vup scipy These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sci-libs/scipy-0.5.1 [0.4.9] USE="fftw -debug" 4,043 kB quoting emerge(1): --update: ... "This will also update direct dependencies which may not be what you want." (which is not happening in my above example) Of course there is also this, which suggests I shouldn't use --update with scipy (why not?): "In general, use this option only in combination with the world or system target." Perhaps related: bug #149092.
I realize that the behavior has changed. However, I think --deep will do what you want, and is makes sense in this case.
Nevermind, I think I see the problem. I make a patch.
Created attachment 98176 [details, diff] update direct dependencies of command line arguments This will bring back the old behavior. Previously we used an "empty" depgraph parameter to produce this type of behavior, but the logic was quite messy in my opinion. I think that this is a much cleaner way to implement it. I'm not sure if we really need the "update direct dependencies" feature anyway. We could get rid of it and people would just have to use --deep to pull in updates of dependencies.
I'm not a big fan of --deep as it tends to put things in a strange order where the direct dependencies end up being emerged after the package itself. See numpy in the following example: # emerge -vuDp scipy These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-devel/binutils-config-1.9-r2 [1.8-r7] 0 kB [ebuild U ] sys-devel/m4-1.4.7 [1.4.6] USE="nls" 499 kB [ebuild U ] sys-apps/debianutils-2.17.1 [2.16.2] USE="-static" 127 kB [ebuild U ] sys-libs/timezone-data-2006l [2006g] 336 kB [ebuild U ] sci-libs/scipy-0.5.1 [0.4.9] USE="fftw -debug" 4,043 kB [ebuild U ] app-admin/perl-cleaner-1.04.3 [1.04.1] 5 kB [ebuild U ] dev-lang/python-2.4.3-r4 [2.4.3-r3] USE="berkdb gdbm ncurses readline ssl tk -bootstrap -build -doc -ipv6 -nocxx -ucs2" 7,827 kB [ebuild U ] dev-java/java-config-2.0.30 [2.0.28-r1] 16 kB [ebuild N ] app-admin/eselect-blas-0.1 0 kB [ebuild N ] app-admin/eselect-cblas-0.1 0 kB [ebuild U ] sci-libs/blas-atlas-3.7.11-r1 [3.7.11] USE="-debug -doc" 1,990 kB [ebuild N ] app-admin/eselect-lapack-0.1 0 kB [ebuild U ] sci-libs/lapack-atlas-3.7.11-r1 [3.7.11] USE="-debug -doc -ifc" 4,934 kB [ebuild U ] dev-python/numpy-1.0_rc1 [1.0_beta2] USE="lapack" 1,094 kB [ebuild U ] x11-drivers/xf86-input-evdev-1.1.2-r2 [1.1.2-r1] USE="-debug" 220 kB I like to old behavior of --update because I could count on it to pull in the most recent versions of the direct dependencies without a lot of other things (and it did it in a predictable order). For example, in this case scipy depends directly on numpy so if I'm interested in the new version of scipy then I'm probably interested in the newer numpy as well. I suppose I wouldn't care so much if --deep put things in a more predictable order (maybe that's a separate bug).
Created attachment 98200 [details, diff] update direct dependencies of command line arguments This updated patch is in svn r4541. (In reply to comment #4) > I'm not a big fan of --deep as it tends to put things in a strange order where > the direct dependencies end up being emerged after the package itself. As long as everything builds correctly and works, we shouldn't be too concerned about the specific ordering. Anyway, the pulling in of direct dependencies seems reasonably useful, so this is fixed for the next release.
Cool! thanks fixing and sorry about the ranting.
This has been released in 2.1.2_pre1-r4.
