Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 283422 - move gcc and glibc to first position of list when emerge -e world
Summary: move gcc and glibc to first position of list when emerge -e world
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 358781 365431 454240 (view as bug list)
Depends on:
Blocks: 144480
  Show dependency tree
 
Reported: 2009-09-01 15:11 UTC by David Carlos Manuelda
Modified: 2016-05-18 03:04 UTC (History)
3 users (show)

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


Attachments
emerge -e world -p output (emergelist.txt.tar.bz2,24.63 KB, application/x-bzip)
2014-03-22 04:54 UTC, David Carlos Manuelda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Carlos Manuelda 2009-09-01 15:11:41 UTC
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
Comment 1 David Carlos Manuelda 2009-09-01 15:21:58 UTC
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.
Comment 2 Zac Medico gentoo-dev 2009-09-01 23:46:40 UTC
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.
Comment 3 David Carlos Manuelda 2009-09-02 10:44:09 UTC
I think it's ok, I only wanted to expose an idea based of what I use :)
Comment 4 SpanKY gentoo-dev 2009-09-06 16:28:27 UTC
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
Comment 5 Ryan Hill (RETIRED) gentoo-dev 2009-09-06 19:53:49 UTC
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.
Comment 6 Zac Medico gentoo-dev 2011-03-14 05:19:04 UTC
*** Bug 358781 has been marked as a duplicate of this bug. ***
Comment 7 Zac Medico gentoo-dev 2011-04-30 20:06:16 UTC
*** Bug 365431 has been marked as a duplicate of this bug. ***
Comment 8 David J Cozatt 2012-08-12 18:40:15 UTC
would not binutils join this list?
Comment 9 Zac Medico gentoo-dev 2013-01-27 19:30:33 UTC
*** Bug 454240 has been marked as a duplicate of this bug. ***
Comment 10 Zac Medico gentoo-dev 2013-01-27 19:38:55 UTC
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.
Comment 11 David J Cozatt 2013-01-31 05:25:38 UTC
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.
Comment 12 David Carlos Manuelda 2014-03-22 04:51:20 UTC
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.
Comment 13 David Carlos Manuelda 2014-03-22 04:53:55 UTC
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).
Comment 14 David Carlos Manuelda 2014-03-22 04:54:17 UTC
Created attachment 373238 [details]
emerge -e world -p output
Comment 15 nobody 2015-04-10 23:45:24 UTC
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.
Comment 16 Brant Gurganus 2016-05-18 03:04:48 UTC
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.