| Summary: | sys-apps/portage-2.1.10.31 portage/env/ and portage/package.env inadequate documentation | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Boney McCracker <brendlerjg> |
| Component: | Documentation | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | bernalex, jer, kamil.kwiek, mjo, StormByte |
| Priority: | Normal | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=409627 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 472632 | ||
| Attachments: | [PATCH] Fixes the bug | ||
(In reply to comment #0) > I have not been using a portage/package.env file, and my portage/env/ entries > seem to be effective. Unless I am imagining this, it would seem that the type > of portage/package.env entries described in the man page are superfluous. package.env is for environment variables only, and it works on in the python side of portage, which allows it to adjust variables like FEATURES and PORTAGE_TMPDIR which need to be adjusted on the python side /etc/portage/env/$CATEGORY/$PN... is for bashrc. These files are sourced in bash, and have no effect on the python side of portage. For this reason, it cannot be used to adjust certain FEATURES or PORTAGE_TMPDIR. > 2) It seems from the 2004 bug that tracked development of this functionality > through 2010 (which I can no longer find to provide you a reference) that the > portage/package.env file may have the capability of setting variables itself, > in lieue of pointing to files in portage/env, but no such capability is > documented in the man page. There is no support for that. For package.env, you have to put the settings in a separate file. > 3) It's not clear what limitations there on the contents of the portage/env/ > files. The man page refers to them as "per-package bashrc" files, which would > imply that any valid bash is okay. This applies to /etc/portage/env/$CATEGORY/$PN... > On the other hand, it also says they should > be in "make.conf format", which implies that bash is not okay, since bash (for > example, conditional expressions), is not valid in make.conf, only > variable=value expressions. This applies to the files that are referenced via package.env. > Also, this would imply that compile-time options > ('--foo=bar' options) are not permitted, but I have used them in > portage/bashrc. Not sure what you mean by '--foo=bar' options. The make.conf format only supports variable settings. Those variables can contain practically string. Some additional explanation:
/etc/portage/env has 2 different meanings:
- bashrc files:
/etc/portage/env/${CATEGORY}/${PN}
/etc/portage/env/${CATEGORY}/${PN}:${SLOT}
/etc/portage/env/${CATEGORY}/${P}
/etc/portage/env/${CATEGORY}/${PF}
- make.conf-like files:
/etc/portage/env/${path}
${path} is used when it is referenced in an entry in
/etc/portage/package.env.
Documentation of package.env mentions only files placed directly in
/etc/portage/env, but it's possible to use subdirectories.
Example:
# emerge -Opv icu
These are the packages that would be merged, in order:
[ebuild R ] dev-libs/icu-4.8.1-r2 USE="doc examples -debug -static-libs" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
# mkdir -p /etc/portage/env/abc/def
# echo USE=static-libs > /etc/portage/env/abc/def/ghi
# echo "dev-libs/icu abc/def/ghi" >> /etc/portage/package.env
# emerge -Opv icu
These are the packages that would be merged, in order:
[ebuild R ] dev-libs/icu-4.8.1-r2 USE="doc examples static-libs* -debug" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
(In reply to comment #2) It's also possible to use files outside of /etc/portage/env. If /etc/portage/package.env contains "category/package ../../some_file", then /etc/some_file will be used. Excellent. That clears things up very nicely for me. It would probably be helpful if, when time allows, the man page included a little more detail on this and distinguished the two areas (python-related portage environment vs. bashrc-configurable build environment). Thank you both for the prompt response and taking the time to explain this. *** Bug 472956 has been marked as a duplicate of this bug. *** *** Bug 475114 has been marked as a duplicate of this bug. *** *** Bug 415053 has been marked as a duplicate of this bug. *** (In reply to John Brendler from comment #4) > It would probably be helpful if, when time allows, the man page included a > little more detail on this and distinguished the two areas (python-related > portage environment vs. bashrc-configurable build environment). Yeah, I think we could clarify the package.env section to state specifically that package.env files are interpreted much earlier than the bashrc files. Created attachment 355724 [details, diff]
[PATCH] Fixes the bug
(In reply to Alexander Berntsen from comment #9) > Created attachment 355724 [details, diff] [details, diff] > [PATCH] Fixes the bug Thanks, this is in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b4a51b2d36676c692bbb5acfd485a849eacb3c10 This is fixed in 2.2.0. |
Minor areas of confusion regarding portage/env/ and portage/package.env, as documented in the portage man page. 1) From what's in the portage man page, it's not clear whether the portage/package.env file is required (along with portage/env/ files) or not: The man page text pertaining to the package.env file says it contains references to files in portage/env. This would seem to imply these entries are required in order that the indicated files in portage/env be sourced. However, the entry pertaining to the portage/env directory indicates that its contents are automatically sourced (like portage/bashrc), based on the category and name of the package being emerged. I have not been using a portage/package.env file, and my portage/env/ entries seem to be effective. Unless I am imagining this, it would seem that the type of portage/package.env entries described in the man page are superfluous. 2) It seems from the 2004 bug that tracked development of this functionality through 2010 (which I can no longer find to provide you a reference) that the portage/package.env file may have the capability of setting variables itself, in lieue of pointing to files in portage/env, but no such capability is documented in the man page. If that capability exists, maybe it should be documented. I'm talking about the portage/package.env file containing 'packagename var1=foo var2=bar'. I'm not saying that capability is needed, just wondering if it was included in the final solution and, if so, noting that it's not documented. 3) It's not clear what limitations there on the contents of the portage/env/ files. The man page refers to them as "per-package bashrc" files, which would imply that any valid bash is okay. On the other hand, it also says they should be in "make.conf format", which implies that bash is not okay, since bash (for example, conditional expressions), is not valid in make.conf, only variable=value expressions. Also, this would imply that compile-time options ('--foo=bar' options) are not permitted, but I have used them in portage/bashrc. A bit of clarification on this might be useful. Reproducible: Always Steps to Reproduce: N/A Actual Results: N/A Expected Results: N/A N/A