Summary: | ROOT=/some/root emerge --emptytree system does not works ? | ||
---|---|---|---|
Product: | Portage Development | Reporter: | xeb <xeb> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | dschridde+gentoobugs, esigra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 137867, 155723 | ||
Attachments: | emerge.log |
Description
xeb
2008-09-30 05:32:08 UTC
Please post emerge --pretend --debug output for the command which you believe is behaving incorrectly. Note that it's normal for it to update build time dependencies (DEPEND) on the main system. Created attachment 166800 [details]
emerge.log
ROOT=/usr/armv5te-softfloat-linux-gnueabi emerge --debug --pretend --emptytree system
you can see it tries to rebuild my system packages instead packages at /usr/armv5te-softfloat-linux-gnueabi
I get the same result here with portage-2.2_rc11. Apparently we need to update all --empty logic so that it only applies to the ROOT that you've selected. ok thanks This was fixed with the introduction --rdeps-only/--root-deps r13245 Should be in the stores near you soon. Any reason this bug is still open? (In reply to comment #6) > Any reason this bug is still open? Looking at the depgraph select_pkg code, it looks like we could tweak the empty logic so it only applies to target_root (like I said in comment #3). Using --root-deps, as suggested in comment #5, makes the symptom go away but the real problem is still there since it should behave correctly even without --root-deps. I suppose the problem could also be considered to extend to most of the options that affect package selection and traversal of the dependency graph. Consider all of the following options: --deep --selective --update --newuse --with-bdeps There's good reason for the user to only want these options to apply to that target root, and do a little a possible to the host root (maybe just install some unsatisfied build-time deps and nothing more). My plan is to take a bunch of these depgraph parameters that currently apply to both target and host roots, and have separate sets of parameters for each root. That should give us all of the flexibility that we need to get any behavior that we desire. Although --root-deps does work, but the the package which depends on it still uses the static archives as installed on the host. As a result kwin fails with -- lto1: fatal error: bytecode stream in file '/usr/lib64/libQt5UiTools.a' generated with LTO version 5.2 instead of the expected 6.0 even though /usr/lib64/libQt5UiTools.a is not build with LTO in ROOT. If I build /usr/lib64/libQt5UiTools.a without LTO in the host, then kwin compiles. |