Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 942602 - sys-apps/portage-3.0.65-r1: ROOT (or SYSROOT) and '--emptytree' misinteract
Summary: sys-apps/portage-3.0.65-r1: ROOT (or SYSROOT) and '--emptytree' misinteract
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-31 13:39 UTC by Stuart Shelton
Modified: 2024-11-02 13:15 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Shelton 2024-10-31 13:39:12 UTC
If the environment variable ROOT is set and has a value other than '/', attempting to build packages with '--emptytree' can cause failures with certain package configurations.

For example, in a situation where sys-devel/gcc has USE flag 'graphite' set and the active CFLAGS use graphite-specific options, the following can occur:

…
ROOT='/' SYSROOT='/' USE='graphite' emerge -k --emptytree sys-devel/gcc dev-libs/isl <some other package> # <- succeeds
ROOT='/build' SYSROOT='/build' USE='graphite' emerge -k --emptytree sys-devel/gcc dev-libs/isl <some other package> # <- fails

… with the failure on the other package being that graphite CFLAGS are specified but GCC hasn't been built with graphite enabled.

Looking in to how this has happened, as a result of the first invocation of 'emerge', GCC has been built into ROOT '/' with the correct flags;

However, on the second invocation of 'emerge', GCC has been built into ROOT '/build' with the correct flags *however* another copy of GCC was also merged into ROOT='/' replacing the former version, without any flags (beyond mandatory/forced ones) set at all.

So when ROOT is not '/', the dependent packages (or just gcc?) in '/' seem to be being replaced with less functional rebuilds with no flags set… which would be mostly invisible, except for when there's a transitive dependency not represented in the package dependency tree such as graphite-related CFLAGS requiring USE='graphite' for sys-devel/gcc.
Comment 1 Stuart Shelton 2024-11-02 13:14:55 UTC
With portage-3.0.66.1 it seems to be worse:

I have a package in an overlay repo which has 'IUSE="-clang openmp …"', and yet dependencies fail to resolve with:

```
export ROOT='/build'
USE='openmp' emerge -kv sys-devel/clang-runtime
USE='-clang openmp' emerge -kv <overlay_package>
USE='-clang openmp' emerge -kv --deep \
    <several_packages_including_overlay_package_and_clang-runtime>
```

… which fails on the final step with an error that sys-devel/clang-runtime requires USE='openmp', despite this flag being set, both packages being explicitly specified, the overlay package only having a dependency on sys-devel/clang-runtime if USE='clang', and the sys-devel/clang-runtime already being installed with USE='openmp'! :(
Comment 2 Stuart Shelton 2024-11-02 13:15:41 UTC
(In reply to Stuart Shelton from comment #1)
> With portage-3.0.66.1 it seems to be worse:

… so, in summary, '--deep' also seems to be effected.
Comment 3 Stuart Shelton 2024-11-02 13:15:53 UTC
(In reply to Stuart Shelton from comment #2)
> (In reply to Stuart Shelton from comment #1)
> > With portage-3.0.66.1 it seems to be worse:
> 
> … so, in summary, '--deep' also seems to be effected.

* affected