I don't know what are exact internal differences between `emerge` and `ebuild` but sometimes when large package like libreoffice failes, I would like to continue compilation with `ebuild` instead of starting whole stuff again with `emerge`. However, though `emerge` supports this variable and lets libreoffice compile when e.g. unsufficient space on the disk, it doesn't work with `ebuild`. Despite what is your opinion about this variable (e.g. #390473) maybe can you at least make `ebuild` accepting it and passing to the actual scripts which will handle it?
To add to above, I know I can edit environment file in the ebuild working directory variable and manually add declare -x I_KNOW_WHAT_I_AM_DOING="yes" which solves it but would be nice to do it without need to play with the files.
(In reply to Rafal Lalik from comment #1) > To add to above, I know I can edit environment file in the ebuild working > directory variable and manually add > > declare -x I_KNOW_WHAT_I_AM_DOING="yes" > > which solves it but would be nice to do it without need to play with the > files. But this is exactly your issue. Because you reuse the environment by not cleaning the ebuild, no new bash variables are added. If you give ebuild such a variable with a clean env, then it does include and is supported.
(In reply to Brian Evans from comment #2) > (In reply to Rafal Lalik from comment #1) > > To add to above, I know I can edit environment file in the ebuild working > > directory variable and manually add > > > > declare -x I_KNOW_WHAT_I_AM_DOING="yes" > > > > which solves it but would be nice to do it without need to play with the > > files. > > But this is exactly your issue. Because you reuse the environment by not > cleaning the ebuild, no new bash variables are added. If you give ebuild > such a variable with a clean env, then it does include and is supported. Right. This is the intended behavior and is covered by the "11.2 The State of Variables Between Functions" section of PMS: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-11400011.2
What I understand, the environment script should has defined all variables set on the creation of environment. So if I call I_KNOW_WHAT_I_AM_DOING=yes emerge ... should the variable be then included in the environment script? or it is only for `ebuild` script?
Both emerge and `ebuild` commands create the environment in exactly the same way. The environment is sealed as soon as it is created, which is necessary in order to fulfill PMS requirements. For example, an ebuild function could unset the I_KNOW_WHAT_I_AM_DOING variable, and according to PMS that variable should remain unset when future ebuild functions are called. Once an ebuild environment is created, we can't add new variables without explicitly violating PMS.
I understand this. I am just wondering, why it is then not stored in the script if I call emerge with this variable set? What I see from greping /usr/portage there are no places where this variable would be unset by ebuild or eclass. So I assume there is no scenario where ebuild would in any way usnet it. So why this variable is missing from environment script when I set it upon calling emerge?
(In reply to Rafal Lalik from comment #6) > I understand this. I am just wondering, why it is then not stored in the > script if I call emerge with this variable set? What I see from greping > /usr/portage there are no places where this variable would be unset by > ebuild or eclass. So I assume there is no scenario where ebuild would in any > way usnet it. > > So why this variable is missing from environment script when I set it upon > calling emerge? Hmm, it seems to be in the environment if I ^C interrupt emerge and grep the environment file: > # I_KNOW_WHAT_I_AM_DOING=1 emerge --nodeps portage > >>> Verifying ebuild manifests > >>> Running pre-merge checks for sys-apps/portage-2.3.78-r2 > * Determining the location of the kernel source code > * Found kernel source directory: > * /usr/src/linux > * Found sources for kernel version: > * 4.19.67-0822 > * Checking for suitable kernel configuration options... [ ok ] > >>> Emerging (1 of 1) sys-apps/portage-2.3.78-r2::gentoo > >>> Jobs: 0 of 1 complete, 1 running Load avg: 1.57, 1.15, 0.98^C > > Exiting on signal 2 > > # grep I_KNOW_WHAT_I_AM_DOING /var/tmp/portage/sys-apps/portage-2.3.78-r2/temp/environment > declare -x I_KNOW_WHAT_I_AM_DOING="1"
NOTE: If you want to add environment variables to an ebuild environment *after* it has been created, it's possible to do so via bashrc files which are documented in the `man 5 portage`: > Portage will source all of these bashrc files after /etc/portage/bashrc in the > following order: > > 1. /etc/portage/env/${CATEGORY}/${PN} > > 2. /etc/portage/env/${CATEGORY}/${PN}:${SLOT} > > 3. /etc/portage/env/${CATEGORY}/${P} > > 4. /etc/portage/env/${CATEGORY}/${PF} The relevant variables are documented in `man 5 ebuild`.
