News:Emul Linux Packages Deprecation

Emul Linux Packages Deprecation

   Important

This news item is not current. You can find updated information on this topic at ABI X86 64 and 32.

Funtoo is switching to true multilib packages. app-emulation/emul-* packages deprecated

By Oleg / April 1, 2015

Starting on 2015-03-29, we are enabling true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds and the security of using mainline ebuilds, rather than relying on pre-packaged binary versions of them.

The switch to the new system is likely to require a specific action from the users of our multilib profiles. Since the new system collides with the old one, the Package Manager must be able to clearly satisfy all the dependencies using the new system in order to proceed. This may require unmerging packages installed from third-party repositories that have not been updated to support the new system.

In order to enable building necessary 32-bit libraries, users will be required to enable the abi_x86_32 USE flag on respective packages. This can be done using /etc/portage/package.use entries alike the following:

   /etc/portage/package.use

sys-libs/zlib abi_x86_32

In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry:

   */* abi_x86_32

In case of issues, blockers especially, users are recommended to manually uninstall any emul-linux-x86 packages that may have been installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command:

root # emerge -C 'app-emulation/emul-linux-x86*'

Note: 32-bit applications may be temporarily broken after this step. Therefore, it should be followed by a @world upgrade immediately