Behavior of emerge with --root and --config-root options

[ivan2k]

Hello all,
I tried to create a new root filesystem with the command:

Code: Select all

USE="build" emerge --root=newroot --config-root=configroot -av1 baselayout

where newroot is an empty target folder and configroot contains portage configuration and files (/etc/portage/*, /var/lib/portage/*, /var/db/repos/gentoo/*).
But emerge complains almost immediately with this error:

!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'enotork:targets/desktop/plasma' not found: '/var/db/repos/local/profiles/desktop/plasma/parent'

The host system has make.profile symlinked to a profile in a local repo in /var/db/repos/local(/profiles/desktop/plasma), which inherits using the parent file from:
- The standard gentoo repo profile default/linux/amd64/23.0/desktop/plasma/systemd
- Another profile in a personal repo (called enotork), synced with git for shared customization across different machines

Portage's configuration inside configroot has make.profile symlinked to default/linux/amd64/23.0/systemd.

Emerge is attempting to resolve the host system profile from the configroot perspective, but fails because there is no enotork repository in configroot.

Of course, if I modify the make.conf symlink on the host system with a gentoo repository profile (also present inside the configroot), there are no complaints.
It seems to me that the --config-root option is not being respected completely.

Why?

[szatox]

Because --config-root is not respected when you use --root.
Build systems typically use a stage3 chroot as an intermediary to avoid polluting your host with build dependencies, so this behavior - although undeniably flawed - is less of an issue in practice than it seems at the first glance.

[ivan2k]

Build systems typically use a stage3 chroot as an intermediary to avoid polluting your host with build dependencies, so this behavior - although undeniably flawed - is less of an issue in practice than it seems at the first glance.

I don't fear polluting the host with build dependencies because the host has a lot of them and the newroot i want to populate is very limited. But yes, the idea of an intermediate stage 3 sounds good.
So i have to download and untar a stage3 somewhere, make configroot and newroot available inside the stage3, chroot into it and run emerge --root --config-root inside. Correct?

Because --config-root is not respected when you use --root.

Do you know the reason behind this implementation? It sounds strange to me ....

[szatox]

I don't know why it's done this way.
Check out "ENVIRONMENT OPTIONS" in man emerge. Funny, I think its contents has changed recently... Anyway, it briefly explains relationships between variables.
I remember using stage3's config as a starting point for making new images. Looks like the preferred way of doing things now is "build baselayout, apply configs, and then emerge the rest of your new system" though.

[sam_]

I don't know why it's done this way.
Check out "ENVIRONMENT OPTIONS" in man emerge. Funny, I think its contents has changed recently... Anyway, it briefly explains relationships between variables.
I remember using stage3's config as a starting point for making new images. Looks like the preferred way of doing things now is "build baselayout, apply configs, and then emerge the rest of your new system" though.

I don't recall any changes there. Anyway, please try be careful not to sound as if a statement is definitive if you're unsure. It's not required to use a stage3. It's the same process as crossdev uses when bootstrapping a new root.

I do think configroot is a bit confusing here especially with how it interacts with the need for BDEPENDs to be satisfied. I am not sure what you're seeing is intended behaviour, no.

[ivan2k]

I do think configroot is a bit confusing here especially with how it interacts with the need for BDEPENDs to be satisfied. I am not sure what you're seeing is intended behaviour, no.

Do you think this is a bug in Portage?

[szatox]

It is documented, so it's a feature, not a bug
Even though it would make more sense to allow pulling configs from arbitrary location, in particular when installing stuff into a ROOT that is not host's system.

[ivan2k]

I don't know if it's related, but i have opened another discussion with a similar problem: https://forums.gentoo.org/viewtopic-p-8 ... ml#8880924

In that scenario is crossdev which use build system flags to build for target system.
Yes, I know that if i don't use custom CFLAGS inside the build system and leave it as a "clean stage3" it will work, but i don't think this is a correct behavior.

[sam_]

It is documented, so it's a feature, not a bug
Even though it would make more sense to allow pulling configs from arbitrary location, in particular when installing stuff into a ROOT that is not host's system.

Where? We should make it clearer at least, and I think it'd be reasonable for ivan2k to file a bug requesting a change as a new feature (possibly under some other option or flag).

[szatox]

Right here:

ENVIRONMENT OPTIONS
EPREFIX = [path]
Use EPREFIX to specify the target prefix to be used for merging packages or ebuilds. This variable can be set via the --prefix option or in make.conf(5) (the command line
overrides other settings).
Defaults to the prefix where portage is currently installed.

ROOT = [path]
Use ROOT to specify the target root filesystem to be used for merging the requested packages or ebuilds and their runtime dependencies. This variable can be set via the
--root option or in make.conf(5) (the command line overrides other settings).
Defaults to /.

SYSROOT = [path]
Use SYSROOT to specify the target root filesystem to be used for merging the build dependencies satisfied by DEPEND. This variable can be set via the --sysroot option or in
make.conf(5) (the command line overrides other settings). The value must either be / or equal to ROOT. When cross-compiling, only the latter is valid.
Defaults to /.

PORTAGE_CONFIGROOT = [path]
Use PORTAGE_CONFIGROOT to specify the location for various portage configuration files (see FILES for a detailed list of configuration files). This variable can be set via
the --config-root option. However, it is now superseded by the SYSROOT variable and can only be given if its value matches SYSROOT or if ROOT=/.
Defaults to /.

I don't understand this decision, I think it is a wrong approach, but it does look intentional to me.