From Gentoo Wiki
Jump to:navigation Jump to:search
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:47, 23 July 2024 (UTC)
:: Your reply ~~~~

Setting FEATURES on specific packages

Talk status
This discussion is done.

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 (talkcontribs) 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, and FEATURES="-ccache -distcc" in package.use, then Portage sees FEATURES set to FEATURES="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)

Directory instead of file

Talk status
This discussion is done as of October 26, 2017.

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 (talkcontribs)

Depends on personal preferences. But describing it as a "file only" as in this article seems indeed wrong.
man5 portage says:
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

Talk status
This discussion is done as of 29 July 2020.

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

Talk status
This discussion is done as of 2022-01-20.

State somewhere that changes from package.env are not shown when using emerge --info See bug: — The preceding unsigned comment was added by Stefan.ku (talkcontribs)

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

Talk status
This discussion is done.

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)
Added this to caveats section. -- Ris (talk) 13:54, 17 November 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

Talk status
This discussion is done.

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 --jobs multiple 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)
Well done, looks great. Thank you! Jlpoole (talk) 18:54, 9 April 2024 (UTC)