Entry #2 – Oct 4th 2016:
One of the unique features of Gentoo are USE flags. They determine what sort of options do we want or don’t want in our software. Ever noticed how audio decoders don’t come with the full set of codecs in Fedora? Or a program handling text doesn’t have support for the language we would like it to have? USE flags address those issues. They allow the user to tailor the whole operating system to his/her needs. There are two main types of USE flags – local and global. The former work on per-application basis, though can be shared between applications with similar functionalities, like audio encoders/decoders. Local USE flags are specified within the /etc/portage/package.use directory in the format “package-group/package-name flag”. Global USE flags apply to the whole system and allow one to define system-wide trends, like “YES to the GTK engine, themes, etc.”, “NO to KDE related libraries”, “NO to Qt graphical libraries”, etc. They’re placed in the /etc/portage/make.conf text file as part of the USE string. Finally, there are also the USE_EXPAND flags that pertain to specific core system components like Ruby, Perl, Python, Apache modules, etc. They can either be defined globally in the /etc/portage/make.conf text file in separate strings (for instance, PYTHON_TARGETS for version-specific, system-wide Python support) or in the /etc/portage/package.use directory as standard USE flags with special syntax (for instance, python_targets_python2_7).
Working with USE flags is initially tricky, especially when we want to install (“emerge”) a lot in one go. Frequent adjustments of both local and global USE flags are part of standard Gentoo maintenance practices. However, eventually we tailor the system to our liking and incremental, weekly updates become less problematic. Still, updates are necessary, like in the case of any other rolling-release distribution. Arch Linux is similar in that manner, though it doesn’t suffer from user mistakes as much. Therefore, always check a full installation query before committing. In the next entry I will talk about Gentoo’s package manager Portage, since it too has some amazing features.
Lastly, I would like to discuss true 64-bit support that so far is only available to Gentoo Linux as part of the USE flag system. One can install a pure 64-bit operating system without support for 32-bit software (“non-multilib”). This is probably useful when building a 64-bit server or embedded device to limit unnecessary clutter of 32-bit libraries. If the kernel is configured with 32-bit ABI support, 32-bit software can then be run in an isolated chroot (secured via some container technology, for instance). However, this entails the obvious need to maintain two systems at the same time – the host non-multilib 64-bit system and the contained 32-bit system. On a standard 64-bit multilib system, 32-bit support can be triggered on a per-application basis using the abi_x86_32 flag. I would strongly discourage this, however. It will mess up the system whenever a 32-bit program is installed, because then a lot of libraries have to be rebuilt with added 32-bit support. it’s better to add 32-bit support globally via the ABI_X86 USE_EXPAND flag in /etc/portage/make.conf.