Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 900465 - sys-apps/portage-3.0.44: `emerge --config` command drops the exported env variables while `emerge` not
Summary: sys-apps/portage-3.0.44: `emerge --config` command drops the exported env var...
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-09 08:00 UTC by Ryan Tsien
Modified: 2023-03-11 17:32 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 Ryan Tsien 2023-03-09 08:00:15 UTC
`emerge` command (like `emerge -vj`) uses the exported customized env variables when install a package, and stores these variables in the '/var/db/pkg/<cate>/<name>-<ver>/environment.bz2' file.

However the `emerge --config` drops the exported customized env variables when executing, so I cannot override the previous stored exported variables.

This inconsistent behavior is so weird! Either none of them should respect the exported env vars, or both should be, I think.

Not sure if it's a special consideration in portage.

Reproducible: Always

Steps to Reproduce:
e.g.: the 'net-misc/keycloak' pkg in my overlay dev branch:
      https://github.com/bekcpear/ryans-repos/tree/dev/net-misc/keycloak-bin

1. # export KC_DB=postgres
2. # emerge -vj net-misc/keycloak
3. # export KC_DB=dev-file
4. # emerge --config net-misc/keycloak
Actual Results:  
Than, you will see the got KC_DB value by pkg_config is still 'postgres', and can't find a way to override it.

Variables that are not stored by the environment.bz2 file cannot be obtained by the pkg_config function either.
Comment 1 Mike Gilbert gentoo-dev 2023-03-09 17:08:58 UTC
This is a side-effect of the PMS requirement that variables set in a given ebuild phase function must be preserved/restored for later phases.

https://projects.gentoo.org/pms/8/pms.html#x1-11400011.2

To accomplish this, Portage saves the variables at the end of each function, and restores them before running the next one.

In this case, it is treating pkg_config as a "later function".

The same behavior happens in pkg_preinst and pkg_postinst when you install a binpkg, for example.
Comment 2 Ryan Tsien 2023-03-09 17:27:11 UTC
I understand what you mean, that is to say, although the execution time of pkg_config may be far away from the time when the package emerges, and pkg_config may be executed many times after that, each pkg_config operation is designed to be strongly associated with the environment in which the package was installed.

Although it is different from what I imagined, it is already understandable.

However, if possible, I still recommend considering pkg_config as a tool to modify the package configuration multiple times in subsequent environments.