I've been thinking the main purpose of emerge -e world, and it is mainly used (at least by me), when a major gcc and glibc is installed. Then, for example, you update from gcc 3.4.x to a 4.x.x, and if you want to do a emerge -e world, you find that gcc and glibc is not in first position, so you need to merge manually gcc first (and change to that profile), and after, it will recompile. My suggestion is to *force* gcc and glibc to be the 2 first items in emerge list which is not harmful anyways and could be usefull. Reproducible: Always
Other thing more: to acomplish that emerge -e world, gcc (and glibc) should be recompiled twice (see bug #283426). A combination of these two bugs could save some time avoiding the double recompile of gcc and glibc to reemerge everything with the new gcc.
It'd rather not hardcode special behavior for any packages. I suppose we could add an option which allows you to specify that certain packages be built/installed asap. Alternatively, it could be done as separate commands and you could use the --exclude option requested in bug #16342 in order to exclude unwanted packages from emerge -e world.
I think it's ok, I only wanted to expose an idea based of what I use :)
adding command line options to manually screw with the dep tree order sounds like a bad idea and something that will largely not be used. if you add the exclude flag, then it should be trivial to get this uncommon (undesired?) behavior: emerge --nodeps <random list of packages> emerge -e world --exclude <random list of packages> in other words, i'd mark this as a dupe of Bug 16342 and call it a day
how about if a user specifies a package and a set on the same command line the packages get installed first? ie. emerge -av gcc glibc @world i guess that takes us back to bug #196877 though anyways, i just use a couple of crappy scripts. http://dev.gentoo.org/~dirtyepic/bin/pkglist http://dev.gentoo.org/~dirtyepic/bin/mergelist # emerge -av gcc glibc # ~/bin/pkglist @world # vi ~/pkg.list # ~/bin/mergelist edit ~/pkg.list to your hearts content before running mergelist.
*** Bug 358781 has been marked as a duplicate of this bug. ***
*** Bug 365431 has been marked as a duplicate of this bug. ***
would not binutils join this list?
*** Bug 454240 has been marked as a duplicate of this bug. ***
We could add support for a @asap package set that would always be automatically promoted to the front of the merge list (only unsatisfied dependencies would be merged before these packages). However, it gets tricky if we want it to consider inter-dependencies inside the @asap set. For example, we already promote virtual/os-headers and virtual/libc automatically, and virtual/os-headers is forced to build before virtual/libc.
Could have a bit of an improvement here if the 'system' subset was built before the rest of the 'world' set. Need to build in order portage, system, world. Obviously deps for each first. Perhaps could create a @toolchain set as a subset of @system If the software and it's deps were built in a previous subsets build just skip the package and go to the next in the chain when building 'world'. I don't see how you get inter-dependency issues if you create the -e world order list> -e system list> -e portage list> build the portage set> then system set> then world set. If a software was built previously skip building that particular software when moving to completing the next set and so on.
Also, 99% of the system, depends on gcc, because they are programmed either in C or C++. That means, that glibc is also involved. That's why I suggested this behaviour and in my opinion it makes sense. It is not about an special option to move them, it is just they are a direct dependency on any gentoo system. I mean, it makes no sense to emerge -e world start compiling any other package than gcc first (specially if the first item is a C/C++ program). An example (from my running gentoo machine) is: emerge -e world -p These are the packages that would be merged, in order: Calculating dependencies ... . .. ..... .. ... done! [ebuild R ] sys-devel/gnuconfig-20140212 0 kB [ebuild R ] dev-libs/lzo-2.06:2 USE="-examples -static-libs" 570 kB [ebuild R ] app-arch/gzip-1.6 USE="-pic -static" 709 kB [ebuild R ] app-misc/mime-types-9 16 kB [ebuild R ] sys-libs/timezone-data-2014a USE="nls" 0 kB [ebuild R ] dev-libs/libebml-1.3.0:0/4 USE="-debug -static-libs" 69 kB [ebuild R ] sys-apps/gentoo-functions-0.3 0 kB [ebuild R ] app-text/poppler-data-0.4.6 4,085 kB [ebuild R ] sys-libs/libutempter-1.1.6-r1 USE="-static-libs" 16 kB [ebuild R ] app-misc/editor-wrapper-4 0 kB [ebuild R ] sys-devel/gcc-config-1.8 15 kB [ebuild R ] sys-apps/which-2.20-r1 133 kB [ebuild R ] sys-devel/patch-2.7.1-r3 USE="-static {-test} -xattr" 661 kB [ebuild R ] sys-apps/baselayout-2.2 USE="-build" 40 kB (...) In this list, there are at least 7 C/C++ programs which will be compiled even before gcc and glibc, so what's the point in that? Besides, when one needs to emerge emptytree world mainly it is because gcc changed to a major version, or even glibc or something similar, which makes this argument stronger in my opinion. But I respect your opinion also, I just want to point out this fact.
I will attach the full emerge -e list. Look the current position of gcc and glibc (in my test, they are far passed the middle of the compile list).
Created attachment 373238 [details] emerge -e world -p output
Could be fine to have such feature, but more tied to a group @toolchain that would be always going first and @system would include @toolchain.
One thing I've thought about here that might help address this is introducing the concept of host vs. build vs. target dependencies to portage. So gcc depends on binutils, but that's really more of a case of a gcc targeting foo depends on a binutils targeting foo. gcc depends on gcc, but it's really more nuanced in that a build of gcc for foo relies on a host gcc targeting foo If those more nuanced dependencies were introduced, that could help getting an appropriate sequencing perhaps though you'd still have issues like gcc depending on things like mpfr and gmp which would have been built with an older gcc. If it truly is important that you end up using the newer gcc for those, if you stored information about the gcc used to build such packages, portage in theory would have the information to know which packages would need rebuilt once the new gcc got built without doing full system or world builds.
