| View previous topic :: View next topic |
| Author |
Message |
russK
l33t
Joined: 27 Jun 2006
Posts: 648
|
 Posted: Sun Jun 22, 2014 12:13 pm Post subject: |
 |
|
| krinn wrote: |
Save one or two trees to even hurt a bit less -> world include system, so if you use -e no need to do system and world, just do world. |
I use only solar and wind power here, and I'm not printing the log files.
Also, I've been though this discussion before, https://forums.gentoo.org/viewtopic-t-480926.html
 |
|
| Back to top |
|
 |
krinn
Watchman
Joined: 02 May 2003
Posts: 7468
|
| Posted: Sun Jun 22, 2014 1:51 pm Post subject: |
|
|
Building twice your toolchain doesn't mean you need to build twice firefox, kde... whatever other stuff you use  |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 22, 2014 3:44 pm Post subject: |
|
|
| russK wrote: | | Do you know if --emptytree implies --with-bdeps y, and if there would be any interaction with -k ? |
As desultory said, it doesn't; in general options don't affect others, unless mentioned in the manpage.
The --with-bdeps option continues as ever, so that for an install action it defaults to n, meaning they won't be pulled in as targets in the same way that runtime dependencies of your @world set are, ie for flags like -u or -N.
They will be updated as needed to fulfil the build-requirements instead.
Again as desultory said, it's much less relevant to an empty-tree situation, especially on a native build, since everything's getting pulled in in any case; even less so when using binpkgs, since there aren't any build-deps for a tbz2.
You can literally untar them to root if you had to, though it is ofc better to use the mangler to track, and later uninstall, files.
Note that the --rebuilt-binaries option is triggered when you use -uD with -K or -G.
Krinn's right that there's no point doing -e both @system and @world, though there may be utility in getting the toolchain in order first. gcc builds itself twice when bootstrapping anyhow, but you want binutils done first, and the gcc deps like gmp; then kernel headers and glibc, and then let the empty-tree run do them all again. However if you're already up to date, there's not much point imo. Just do the -e @world run. OFC it's your machine, and you can do what you like; if your experience tells you otherwise, I'm not one to argue. I just like discussing the toolchain and empty-tree builds for some odd reason ;)
| Quote: | | I'm trying to wrap my head around whether portage would choose to use a binpkg or rebuild a new one, depending on the origin of the binpkg. |
Not depending on the origin; just on whether the binpkg fulfils the requirements. The usual thing that used to make it rebuild, assuming you otherwise have the right version available, is a difference in USE flags. The --binpkg-respect-use option is there now, and defaults to n, which means it will install them even if they have different USE settings, so long as they don't conflict with an explicit dependency requirement (I hope;) It's been a while since I used binpkgs. You might want to set it to y if you want them to rebuild from source to match the settings, eg on the actual build-machine, and leave it alone on the clients. |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 648
|
| Posted: Tue Jun 24, 2014 2:49 am Post subject: |
|
|
| steveL wrote: | I just like discussing the toolchain and empty-tree builds for some odd reason  |
Same here 
| steveL wrote: | | russK wrote: | | I'm trying to wrap my head around whether portage would choose to use a binpkg or rebuild a new one, depending on the origin of the binpkg. |
Not depending on the origin; just on whether the binpkg fulfils the requirements. The usual thing that used to make it rebuild, assuming you otherwise have the right version available, is a difference in USE flags. The --binpkg-respect-use option is there now, and defaults to n, which means it will install them even if they have different USE settings, so long as they don't conflict with an explicit dependency requirement (I hope;) It's been a while since I used binpkgs. You might want to set it to y if you want them to rebuild from source to match the settings, eg on the actual build-machine, and leave it alone on the clients. |
Ah yes, '--binpkg-respect-use y' is pretty much what I was thinking about, but also I suppose I might worry or wonder about CFLAGS and such, and at that point if I thought it was important I would use '--usepkg n'
So I recently put buildpkg in my FEATURES as NeddySeagoon suggested, and ran an entire 'emerge -e @world', so now when I enter 'emerge -k -e @world', I get:
| Code: |
emerge -e -k @world --ask
[... snip ...]
[binary R ] virtual/notification-daemon-0
[binary R ] gnome-extra/nm-applet-0.9.8.8-r2
[binary R ] gnome-base/gdm-3.10.0.1-r1
[binary R ] gnome-base/gnome-core-apps-3.10.0
[binary R ] gnome-extra/gnome-tweak-tool-3.10.1
[binary R ] app-admin/eselect-gnome-shell-extensions-20120911
[binary R ] gnome-extra/gnome-shell-extensions-3.10.1
[binary R ] gnome-base/gnome-extra-apps-3.10.0-r1
[binary R ] gnome-base/gnome-3.10.0
Would you like to merge these packages? [Yes/No]
|
That's pretty cool. Especially considering I have 1 short of 1400 packages installed:
| Code: | # equery list '*' | wc -l
1399
# |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Jun 24, 2014 10:19 pm Post subject: |
|
|
| russK wrote: | | That's pretty cool. Especially considering I have 1 short of 1400 packages installed |
Yeah it's very spooky watching emerge build from binhosts, as quick as a bindist. (Though ofc you don't want to do that to rebuild world;) I did a lot of that in the "summer of expat", when we were testing ABI warnings in update (many, many builds in chroot to test what the script would do, and automate it correctly before my boss would allow it to run on real machines; it's why we added multi-binhost support.)
There's another tip about buildpkg in that thread (basic, you've done it already). Was thinking it'd be good to do a snapshot script that does a backup (including simple hardlink) of current vdb packages, so you could replicate your install (given that you have it in FEATURES. qpkg is not as nice.)
To do it right you'd really want to export them as a portage tree, so exactly what you have is what gets installed. Hmm. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
