somewhere between 2.1.3.9 and 2.1.3.12 emerge started ignoring the order of the packages given on the command line. i'm thinking the resolver is being overambitious and trying to find the optimal build sequence. but when the user explicitly specifies a particular ordering i think emerge should do its best to honor it. for example, if i'm building/upgrading a toolchain i generally want linux-headers to build before glibc and glibc before gcc. dirtyepic@tycho ~ $ emerge --info | grep Portage Portage 2.1.3.9 (default-linux/x86/2007.0, gcc-4.2.3-pre20071009, glibc-2.6.1-r0, 2.6.23.1 i686) dirtyepic@tycho ~ $ emerge -pv linux-headers glibc binutils gcc [ebuild R ] sys-kernel/linux-headers-2.6.23 0 kB [ebuild U ] sys-libs/glibc-2.7 [2.6.1] USE="glibc-omitfp -debug -glibc-compat20 (-hardened) (-multilib) -nls -profile (-selinux)" 16,211 kB [ebuild R ] sys-devel/binutils-2.18.50.0.2 USE="multislot test -multitarget -nls -vanilla" 0 kB [ebuild U ] sys-devel/gcc-4.2.3_pre20071023 [4.2.3_pre20071009] USE="openmp test (-altivec) -bootstrap -build -doc -fortran -gcj -gtk (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nls -nocxx -objc -objc++ -objc-gc -vanilla" 0 kB [1] dirtyepic@tycho ~ $ emerge --info | grep Portage Portage 2.1.3.12 (default-linux/x86/2007.0, gcc-4.2.3-pre20071009, glibc-2.6.1-r0, 2.6.23.1 i686) dirtyepic@tycho ~ $ emerge -pv linux-headers glibc binutils gcc [ebuild R ] sys-devel/binutils-2.18.50.0.2 USE="multislot test -multitarget -nls -vanilla" 0 kB [ebuild R ] sys-kernel/linux-headers-2.6.23 0 kB [ebuild U ] sys-devel/gcc-4.2.3_pre20071023 [4.2.3_pre20071009] USE="openmp test (-altivec) -bootstrap -build -doc -fortran -gcj -gtk (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nls -nocxx -objc -objc++ -objc-gc -vanilla" 0 kB [1] [ebuild U ] sys-libs/glibc-2.7 [2.6.1] USE="glibc-omitfp -debug -glibc-compat20 (-hardened) (-multilib) -nls -profile (-selinux)" 16,211 kB
If you don't want it to try to optimize build order then --nodeps is one way to do it. I think the default behavior should be for it use dependencies to optimize order as much as possible. Is --nodeps sufficient for you needs?
yeah that'll work. :)
How about this case: elmer ~ # PORTAGE_TMPDIR=/dev/shm/ emergetest -va1 =sys-devel/binutils-2.18-r3 = sci-physics/geant-4.9.1_p02 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sci-physics/clhep-2.0.3.3 USE="-exceptions" 4,936 kB [ebuild U ] sys-devel/binutils-2.18-r3 [2.18-r1] USE="nls test -multislot -m ultitarget -vanilla" 17 kB [ebuild N ] sci-physics/geant-4.9.1_p02 USE="data examples motif opengl ray tracerx vrml zlib -athena -dawn -debug -gdml -geant3 -global -minimal -openinven tor -static" 86,966 kB Total: 3 packages (1 upgrade, 2 new), Size of downloads: 91,918 kB Would you like to merge these packages? [Yes/No] I clearly asked to do binutils first. There's not reason why a new package that is a dependency of another new package should be emerged before an installed one is upgraded.
(In reply to comment #3) > I clearly asked to do binutils first. There's not reason why a new package that > is a dependency of another new package should be emerged before an installed > one is upgraded. Okay, so maybe the order can more optimal. However, when it comes to respecting merge order on the command line, I don't want to support it in any case but the --nodeps case. Yes, I will try to optimize the merge order more, but if the merge order is being calculated based on dependencies then I don't want to also factor in the order given on the command line. Unless --nodeps is enabled, I want the merge order to be solely determined by package dependencies.
