Global vs package specific USE — best practice

Question

I'll be installing Gentoo for the first time and as a preparation I am crawling Gentoo wiki for packages I'll need and what USE flags those packages use.

What I am not sure about is at what level I should put the keywords.
I read the Handbook:AMD64/Working/USE, but if I read it correctly, it doesn't recommend when to put the USE-flag globally (/etc/portage/make.conf) and when to put the USE-flag at the package level (/etc/portage/package.use).

Is there a best practice for this? Or shall I just take my best guess at which USE keywords might be influencing enough packages to put such USE keyword at the global level ?

Answer 1

Gentoo is about flexibility in some sense, so you can do whatever works for you, but things do tend to work more smoothly the more you can stick to the defaults. Given that, when in doubt, it's probably better to apply USE flags to specific packages using /etc/portage/package.use whenever possible. If you find yourself setting the same USE flag for several different packages and it's something you anticipate being useful to set system-wide, then you can move it to make.conf.

Anecdotally, the USE flags that are most valuable to set in make.conf tend to be ones referring to uncommon hardware devices your system has (bluray, bluetooth, wifi) or optional features that are common to many programs which you want available (cjk, unicode, xattr).

Answer 2

it doesn't recommend when to put the USE keyword globally (/etc/portage/make.conf) and when to put the USE keyword at the package level (/etc/portage/package.use).

Well, the wiki does somehow :

It is often preferable to set USE flags per package rather than system wide. Use flag defaults are usually set to a sane default - carefully consider what flags to set globally in make.conf.

And as if it wasn't enough, once again :

In any case, as much as possible, no USE flags should be set in make.conf unless necessary, and /etc/portage/package.use should be preferred to set USE flags on a per-package basis. Following this advice should ease system administration in the long run.

Of course, if you know your hardware well and know it won't change, you can safely fix the state of associated flags (such as, bluetooth, bluray, dc1394, fdformat, ieee1394, iec61883, ios, lirc, numa, parport, pxeserial, scanner, serialport, smartcard, wifi, wireless) into make.conf. As well with system-ffmpeg system-harfbuzz system-jpeg system-icu system-libevent system-libvpx system-png system-ssl system-zlib system-webp if you systematically want your packages to rely on system libraries (rather than on some package local implementation)
Or even, like me, because of some philosophy a priori : -systemd -pulseaudio ;-)

You should not worry that much anyway since definitions in package.use supersede those in make.conf.

I, for example have system-png set in my make.conf but, because of some incompatibility with firefox, set -system-png for firefox in package.use

In any case, for each package you want to install, do fire equery use <package_name> that will list all the possible use flags for that package.
Flags that should in no way be set globally (in make.conf) are generally indicated.

Answer 3

I'm going to take a stab at this one as I've been using Gentoo as my daily Linux Driver for nearly 20 years.

Inheritance

The reason most users who attempt to tackle the mess that is Gentoo become overwhelmed or frustrated is because they are misunderstanding the principle of object inheritance. If we treat the USE flags listed at Gentoo Support: USE Flags as objects, the inheritance begins to take shape

USE Flag Precedence

In the same way that all Object Oriented Languages have a Base Class (the class that all other classes are built from), Gentoo has Base Configs. These configs are called Profiles. The USE Flags set in those profiles give the user the ability to start with sane defaults as those USE Flags are applied system-wide whether set in make.conf or not.

The precedence is as follows:

1. Profile - /var/db/repos/gentoo/profiles: Symlinked to /etc/portage/profile
2. Portage's Make.conf - /etc/portage/make.conf: This file allows you to add or remove USE Flags to the base profile without altering the base Profile
3. Portage's Package.use - /etc/portage/package.use: This file sets USE Flags on a per package basis, i.e., if I wanted to add CGI support to Apache and no other package, I would add it here with: www-servers/apache cgi
   • Note: This can also be a directory containing files of package names or related sets. In my example the Filename would be webservers.use and contain the same entry

This precedence also works with .mask files. A mask is used to deny package installation or USE Flags. I prefer not to update my kernels as soon as a new kernel is released to the tree, so as a working example, I have the following entry in /etc/portage/package.mask:

>=sys-kernel/gentoo-sources:6.6.21

This gives me access to every kernel in the portage tree except the 6.6 series. I'll update the mask as soon as a kernel bigger than 6.6 is out, thereby staying 1 stable kernel behind what's current.

Examples

1. I want to install a basic system with sane defaults with only X but no Desktop Environment:
   • Select the barebones Profile:eselect profile list && eselect profile set 1
   • I then add X to /etc/portage/make.conf
   • I update the system: emerge -uDavN --with-bdeps=y @world
2. I decide I'm not as Linux proficient as I thought and need a Desktop Environment and I've used KDE before:
   • Select the KDE Profile: eselect profile list && eselect profile set 4
   • I can now remove X from /etc/portage/make.conf because it's a required dependency of KDE, which means it's listed in the Profile I just chose, and I don't want it listed twice in case I need to debug later.
   • I update the system again: emerge -uDavN --with-bdeps=y @world Note that X isn't pulled in twice, but may be rebuilt depending on the Profile USE Flags
3. Well darn, I've got a browser and an email program now, but every tutorial or article I look at is using System Daemon and I've got this crusty old SysV init. I think I'll upgrade so the tutorials etc. make more sense (Note that if you weren't using Gentoo, you'd have to reinstall an OS thats installer supported systemd from the outset, but because there is a profile for this exact scenario you can freely switch, although I only recommend doing it once):
   • See: Gentoo Wiki: SystemD - Select the SystemD only Profile (22) according to the KDE Wiki.
   • Complete the conversion: emerge -uDavN --with-bdeps=y @world
   • Install KDE: Gentoo Wiki: KDE. Select Profile 28 (KDE + SystemD)
   • Complete the KDE install: emerge -uDavN --with-bdeps=y @world
4. Well, I finished all that so let's try some music. I open Pandora and there's no music (This could be a kernel configuration change, but for this example I'm assuming broken speakers). Now I need to disable alsa and pipewire while I figure this out:
   • alsa and pipewire are both globally set in the Profile in Example 3, so I need to disable them:
     • Edit /etc/portage/make.conf to read: USE="-alsa -pipewire"
     • Rebuild the system again: emerge -uDavN --with-bdeps=y @world

Conclusion

In exchange for multiple compiles and many more circular dependencies during regular upgrades and changes, the OP will receive the following:

1. A highly customized system.
2. A deeper understanding of how all Linux distributions function. There are no fancy configurators, one is expected to edit config files in the /etc directory and others by hand when using Gentoo.
3. That deeper understanding comes in handy on places like this exchange where one will be able to help others regardless of the distribution chosen because one now realizes all Linux distributions are built from nearly the same sources, and only the package managers change.