# use flags, best practices

## venomfang

I have just started to take the dive into gentoo.

I have found the documentation to be very good, except around use flags for portage.

My question is what is the best way to deal with them?  Does portage automatically add the appropriate use flags when installing software with emerge?

Seperating only needed use flags for each app would sound the best, but that looks like a lot of work.

----------

## Logicien

For the understanding of the features of each package set USE flags by package is the best. That let the default USE flags of an ebuild untouch until you or emerge (ask to) change them.

The problem is that you have to check every package USE flags to be sure they correspond to what you want and is needed. At the beginning of a Gentoo installation it's requiert a lot of attention. After it is finish, very less. I never set a USE flag only for a package version but for all versions, I mean no version is specify for a package. So the USE flag can be use for all versions. It's require less USE flags management.

Setting globally the USE flags is easier, but that's imply modifying the defaults USE flags of all ebuilds that are concerned. At the beginning of my Gentoo installation, I set USE flags per case only, since it is finish, I put the most important and common USE flags to /etc/portage/make.conf and remove them from /etc/portage/package.use. This is optional. It's only affect the new packages I can install.

Global and per case USE flags both work, it's a matter of taste too.

----------

## steveL

Usually we setup with ufed for global overall settings at install.

Then if you want to change a global setting later on you can use euse (gentoolkit) from command-line, or just edit /etc/portage/make.conf.

In general, I prefer setting USE flags per-package, if it's not something like ssse3 or "-consolekit -policykit -semantic-desktop -udisks -upower" which applies to my whole system. I find update (git version) much the best way to manage these, since I can just hit e/E for a dialog list-editor, which enables me to see the local descriptions for each flag on a per-package basis (ie select it from list, and then hit "Edit USE"), and enable or disable flags, usually for the package but globally if I choose.

It also manages a lot of other stuff for me, so I can worry just about what portage is saying, not how to act on it, since update will do it for me (and I get to see a coloured diff of any config changes, so I don't lose touch with where the settings are.)

Other than that, get used to using /etc/portage/package.use.

----------

## 666threesixes666

stevel can you please fix this?

https://wiki.gentoo.org/wiki/USE_flag

you clearly know use flags much better than i do....  my understanding is hierarchy of profile setting a bunch of use flags that i don't know about, then make.conf, then package.use

----------

## steveL

666: I think the Gentoo doc you link to says it all really; the most I could think to add is that USE-flags often, but not always by any means, affect configure flags (and that's how I remember them first being described to me.) Nowadays they're much broader, but it's a good way to get your head round them.

----------

## steveL

666: doh you're right it doesn't mention the ordering; you have it right afaik: profile, then make.conf, and finally package.use.

Profiles are the tricky part: you have to look for the "parent" file which is a relative symlink, and then keep following that up the stack; now invert and that's the order. They usually start from default/linux.

There've been some changes recently to portage which have resulted in a metadata layout thing as well. Not really sure how that works: it sounded an awful lot more complicated when Arfrever explained it in #-portage, but also pretty comprehensive.

----------

## phajdan.jr

 *venomfang wrote:*   

> Does portage automatically add the appropriate use flags when installing software with emerge?

 

It doesn't. At some point in Gentoo history USE flags could be implicitly turned on by installing packages (e.g. installing cups would turn USE=cups on), but it led to surprising problems, so now we're applying "explicit is better than implicit" philosophy here.

 *venomfang wrote:*   

> Seperating only needed use flags for each app would sound the best, but that looks like a lot of work.

 

Yes, that's generally my recommended approach: stick to the defaults, and when you need something or something is missing, enable or disable a flag.

----------

## The Doctor

My approach is basically to categorize use flags into major categories.

First, what I want. For example, I generally want Xorg support so I have X. Also, since I use mdev I have that flag on.

Next, what I don't want. For example, I generally don't want gnome or gtk enabled as I prefer qt4. Since I don't have any bluetooth hardware, I also disable that, and so on. 

Last, it is the per package settings. For example, one package may require gtk to work or it may have a package specific option.

When in doubt, I generally consult this document. In general, if you don't have a reason to set something either way leave it alone. Some packages have default options that you don't want to arbitrarily override them.

Using use flags correctly can be a great benefit. Just remember, if you mess something up it is your job to pick up the pieces.

----------

## crade

The way I have found best to handle USE flags is to set the general stuff you want system wide in your make.conf (in my case -gnome, -qt4, -firefox, pulseaudio) something like that..

then when installing your packages, check the emerge first to see what the options are for the package and if it pulls in a bunch of dependencies that it shouldn't need (imho) and adjust the flags at the package level for that package (and potentially dependency packages) appropriately at that time.

I have found that it's usually not a good idea to put very many "add" USE flags in your global settings..  A positive use flag often means more to a particular package than just having something installed.  It can also have versioning and use flag requirements that you might not want to impose on your system for no reason (ie: you don't really need or use gtk support on git, it's just automatically added because you have gtk).

----------

