Talk:/etc/portage/package.env
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 11:40, 5 November 2024 (UTC) :: Your reply ~~~~
Setting FEATURES on specific packages
I might be wrong, but I think that the env files only "add" stuff to the default configs. If so, it should be stated in the article.
My case is: I have enabled ccache and distcc in my make.conf. Now, if I want to disable ccache and distcc for virtualbox (the compilation notoriously fails with them...), I think it works only when I specify FEATURES="-ccache -distcc"
Initially, I have put FEATURES="", to clear the FEATURES flag, but it didn't work. — Preceding unsigned comment added by Kupusc (talk • contribs) 05:18, March 7, 2016
- Hi Kupusc , I can look into this. I need to enhance my Portage skillz anyway. I'll close the discussion when I find the answer. Also, please remember to sign your comments on discussion packages. The button is in the formatting box. Kind regards, --Maffblaster (talk) 20:06, 7 December 2016 (UTC)
- Have an answer! It should work on a per-package basis but be aware the FEATURES variable is an incremental variable, meaning if it's already specified in /etc/portage/make.conf then Portage will read the values from the make.conf definition, and then read the values from the /etc/portage/package.use file/directory. In other words if
FEATURES="ccache distcc"in make.conf, andFEATURES="-ccache -distcc"in package.use, then Portage sees FEATURES set toFEATURES="ccache distcc -ccache -distcc"at emerge time. This ultimately results in ccache and distcc being disabled, as you intend. Hopefully that makes sense. --Maffblaster (talk) 23:00, 5 January 2017 (UTC)
- Have an answer! It should work on a per-package basis but be aware the FEATURES variable is an incremental variable, meaning if it's already specified in /etc/portage/make.conf then Portage will read the values from the make.conf definition, and then read the values from the /etc/portage/package.use file/directory. In other words if
Directory instead of file
Shouldn't /etc/portage/package.env be rather used as directory with modular files for every package inside, instead of being one big file with a list of all packages? — The preceding unsigned comment was added by Pygospa (talk • contribs)
- Depends on personal preferences. But describing it as a "file only" as in this article seems indeed wrong.
man5 portage says:
etc/portage/ Files in this directory including make.conf, repos.conf, and any file with a name that begins with "package." can be more than just a flat file. If it is a directory, then all the files in that directory will be sorted in ascending alphabetical order by file name and summed together as if it were a single file.
--Charles17 (talk) 11:10, 4 August 2017 (UTC)
entries starting with <=, = and (=> or nothing) operators
Shouldn't these apparent operators be documented here? --necktwi (talk) 11:20, 2 September 2018 (IST)
- The referenced "operators" are nowhere to be found in this article. Your complaint is a non sequitur. --Davidbryant (talk) 15:41, 29 July 2020 (UTC)
emerge --info not showing changes from package.env
State somewhere that changes from package.env are not shown when using emerge --info See bug: https://bugs.gentoo.org/410069 — The preceding unsigned comment was added by Stefan.ku (talk • contribs)
- The following section has been added in order to address the above concern: Special:Diff/1037442/1044057. --Maffblaster (talk) 22:59, 20 January 2022 (UTC)
crossdev requires package.env to be a directory instead of file
The package sys-devel/crossdev, at least on version 20220818 (sys-devel/crossdev-20220818), requires /etc/portage/package.env to be a directory.
I had it as a file and after emerging the package i got the following error:
- error: please convert //etc/portage/package.env to a directory
I haven't edited the page directly because I don't see a specific place to add such a comment and some modifications to the structure of the page may be in order. --Patomas (talk) 10:35, 1 October 2022 (UTC)
- That's a good thing to know when setting up the package.env config - thanks. Feel free to add the info to the article, even if it needs a little structural change ;). Some articles have a "tips" section, many have "troubleshooting", though glancing at it, maybe the info could go in a subsection "caveats", if not elsewhere. In any cast, thanks for the heads up!! -- Ris (talk) 15:23, 1 October 2022 (UTC)
Page title
After my latest changes, the article covers even more /etc/portage/env. /etc/portage/env and /etc/portage/package.env seem indissociable, maybe a better title would be "/etc/portage/env and /etc/portage/package.env" ? I'd just make the change, but there are lot of pages linking here, so it is not trivial - I think we should decide if a change is needed first, and what to change it to. -- Ris (talk) 14:01, 17 November 2022 (UTC)
MAKEOPTS Override Suggestion
I came to this page because I tried to build dev-qt/qtwebengine on my system with 32 CPU, and while I have dedicated 64 GB of ram, the gcc 2 * No. of threads, e.g. 64 GB, caused the build to fail. So for this package, dev-qt/qtwebengine, I wanted to create a file that made an exception. The question I had is if I can define MAKEOPTS=$MAKEOPTS."-j28 " and know that my "-j 28" would override any previous definitions of "jobs [e.g. -j]" in MAKEOPTS defined in /etc/portage/make.conf. Having a hint here that the last option pair on an options line overrides any previous ones on the line would be helpful... if that is the case. Since I do not know the answer to that question, I thought it would be helpful to have some something addressing that question here so users can create overrides without dropping any other configurations in MAKEOPTS, they simply override the "-j" setting and by placing it in this special config file, e.g. /etc/portage/env/limit_ram.conf, using the convention of MAKEOPTS=$MAKEOPTS."[overrides]" without loss of other settings. And, the caveat that the last override found any in files supersedes previous ones.
Jlpoole (talk) 15:20, 9 April 2024 (UTC)
- Thank you for your suggestion!
- MAKEOPTS is just a list of variables that get passed to make, so you can check make(1) to see what happens when specifying
--jobsmultiple times. - However, MAKEOPTS#MAKEOPTS on a per-package basis links to this page:
Packages can be emerged with different MAKEOPTS values on a per-package basis. See /etc/portage/package.env for details.
- And yet I couldn't find any mention of MAKEOPTS, so I went ahead and added section /etc/portage/package.env#Use different MAKEOPTS for a specific package.
- Please take a look and tell me what you think. — Waldo Lemmer 18:20, 9 April 2024 (UTC)
/etc/portage/env
Currently there is no wiki for this location. Eventhough the man-page says in section "package.env" "Beginners should be careful to recognize the difference between these two types", it's not clearly described in the later section "/etc/portage/env/". The Wiki does not make it clearer. From my understanding, in /etc/portage/env there can be 2 type of files. One is placed in the parent dir and must be referenced by /etc/portage/package.env entries, the other is placed like /etc/portage/env/${CATEGORY}/${PN}. The difference is the time of sourcing.
Then there is package.bashrc with referenced files located in bashrc/ but in section "bashrc" of the man-page I read "Additional package-specific bashrc files can be created in /etc/portage/env.".
I'm confused. Is there somewhere the complete call-stack of all env and bashrc files? Forum thread for further discussion: https://forums.gentoo.org/viewtopic-t-1170706.html --Massimo B. (talk) 07:48, 5 September 2024 (UTC)