[gentoo-user] Python 3.11 USE flags being flipped on

[s***@shitposting.expert]

I just tried to run today's emerge, when I saw that python 3.11 was
being pulled in and packages had this USE flag flipped on.
I tried masking the USE flags for python 3.11 and that had the effect of
creating the same problem, but with python 3.10 instead.
After masking python 3.10 too, I get this:

$ emergeallk @world

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 3.38 s (backtrack: 0/20).


!!! Multiple package instances within a single package slot have been
pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/python-exec:2

(dev-lang/python-exec-2.4.10:2/2::gentoo, ebuild scheduled for merge)
USE="(native-symlinks) -test" PYTHON_TARGETS="(pypy3) (python3_12)
(-python3_10) (-python3_11)" pulled in by
(no parents that aren't satisfied by other packages in this slot)

(dev-lang/python-exec-2.4.10:2/2::gentoo, installed)
USE="(native-symlinks) -test" PYTHON_TARGETS="(pypy3) (python3_10)
(python3_11) (python3_12)" pulled in by
dev-lang/python-exec[python_targets_python3_11(-)] required by
(dev-lang/python-3.11.6:3.11/3.11::libressl, installed) USE="ensurepip
gdbm lto ncurses pgo sqlite ssl verify-sig -bluetooth -build -debug
-examples -libedit -readline -test -tk -valgrind"





It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


emerge: there are no ebuilds to satisfy
">=dev-python/mako-0.8.0[python_targets_python3_11(-)]".
(dependency required by "media-libs/mesa-23.3.1::gentoo" [ebuild])
(dependency required by
"x11-base/xorg-server-21.1.10-r1::gentoo[-minimal]" [ebuild])
(dependency required by
"x11-drivers/xf86-input-keyboard-1.9.0-r1::gentoo-static" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

Any ideas?

[Nikos Chantziaras]

Post by s***@shitposting.expert
I just tried to run today's emerge, when I saw that python 3.11 was
being pulled in and packages had this USE flag flipped on.

Python 3.11 is the default right now (and has been for some months now.)
You should follow the python upgrade procedure (there should be a news
item for this, you can view those with "eselect news list".)

After the upgrade, it might be easier to block new python versions until
Gentoo switches the default version again later. This has been a
mainstay in my packacke.mask for ages now:

# Prevent a shitload of different python versions from being installed
<=dev-lang/python-3.10

Post by s***@shitposting.expert
=dev-lang/python-3.12

(Obviously the versions are gonna differ over time.)

I don't set PYTHON_TARGETS nor PYTHON_SINGLE_TARGET. Currently, the
defaults are:

PYTHON_SINGLE_TARGET="python3_11"
PYTHON_TARGETS="python3_11"

When the default Python version changes, this is usually announced
through a portage news item and you'll get a notification about it when
you sync.

If you really want to stick to 3.10, you can try setting the above vars
for portage. You can do this in your package.use:

*/* PYTHON_TARGETS: -* python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_10

However, 3.11 is the current default for a reason. Maybe some packages
really require it, and thus you will end up with both 3.10 and 3.11
installed. If you just want a single version installed, then it's a good
idea to not go against the current portage default.

[s***@shitposting.expert]

Post by Nikos Chantziaras

Post by s***@shitposting.expert
I just tried to run today's emerge, when I saw that python 3.11 was
being pulled in and packages had this USE flag flipped on.

Python 3.11 is the default right now (and has been for some months
now.) You should follow the python upgrade procedure (there should be
a news item for this, you can view those with "eselect news list".)
After the upgrade, it might be easier to block new python versions
until Gentoo switches the default version again later. This has been a
# Prevent a shitload of different python versions from being
installed
<=dev-lang/python-3.10

Post by s***@shitposting.expert
=dev-lang/python-3.12

(Obviously the versions are gonna differ over time.)
I don't set PYTHON_TARGETS nor PYTHON_SINGLE_TARGET. Currently, the
PYTHON_SINGLE_TARGET="python3_11"
PYTHON_TARGETS="python3_11"
When the default Python version changes, this is usually announced
through a portage news item and you'll get a notification about it
when you sync.
If you really want to stick to 3.10, you can try setting the above
*/* PYTHON_TARGETS: -* python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_10
However, 3.11 is the current default for a reason. Maybe some packages
really require it, and thus you will end up with both 3.10 and 3.11
installed. If you just want a single version installed, then it's a
good idea to not go against the current portage default.

I have done the migration to python 3.12.
The problem is that portage is pulling in python 3.11.

I have PYTHON_TARGETS="python3_12" in make.conf.
And:
app-eselect/eselect-repository python_single_target_python3_12
media-video/mpv python_single_target_python3_12
dev-util/glib-utils python_single_target_python3_12

In package.use

Putting PYTHON_SINGLE_TARGET="python3_12" in make.conf changes nothing.

The problem is that I'm on python 3.12 and portage is pulling in an
older version.

[Arve Barsnes]

Post by s***@shitposting.expert
The problem is that I'm on python 3.12 and portage is pulling in an
older version.

Should have mentioned it in the first post, then it would be easy to
look into it and tell you that media-libs/mesa is only supported up to
3.11 (in the ebuild anyway). You can try adding 3.12 to the ebuild
yourself, as it seems to be working fine according to
https://bugs.gentoo.org/919912

Regards,
Arve

[s***@shitposting.expert]

Post by Arve Barsnes

Post by s***@shitposting.expert
The problem is that I'm on python 3.12 and portage is pulling in an
older version.

Should have mentioned it in the first post, then it would be easy to
look into it and tell you that media-libs/mesa is only supported up to
3.11 (in the ebuild anyway). You can try adding 3.12 to the ebuild
yourself, as it seems to be working fine according to
https://bugs.gentoo.org/919912
Regards,
Arve

Thanks.
But why did this happen now, and not when I migrated to python 3.12?

[Martin Vaeth]

Post by s***@shitposting.expert
I have done the migration to python 3.12.
The problem is that portage is pulling in python 3.11.

A python version jump in gentoo is always a horrible work:
Many ebuilds have not been updated and pull in unnecessarily
python 3.11. If you use any of these packages, you need a patched
version of them in your overlay.

The list is not complete, even less if you have USE=python in
some packages.

The most notable package is www-client/firefox which is the only
one which actually *needs* <python-3.12 - the others just have
a broken dependency declaration.




app-crypt/gcr
app-portage/gverify
app-portage/mirrorselect
app-portage/overlint
app-text/iso-codes
dev-cpp/atkmm
dev-cpp/glibmm
dev-cpp/pangomm
dev-libs/glib
dev-libs/gobject-introspection
dev-libs/libevdev
dev-libs/libinput
dev-libs/jsoncpp
dev-libs/newt
dev-libs/zziplib
dev-python/ssl-fetch
dev-util/flawfinder
dev-util/intel_clc
gui-libs/gtk-layer-shell
gui-libs/vte-common
media-gfx/sane-backends
media-libs/avidemux-plugins
media-libs/fcft
media-libs/gegl
media-libs/graphene
media-libs/libaom
media-libs/libepoxy
media-libs/libglvnd
media-libs/libmypaint
media-libs/mesa
media-libs/opus
net-libs/libmbim
net-libs/nodejs
sys-apps/merge-usr
sys-boot/grub
sys-process/htop
www-client/firefox
x11-libs/vte
x11-themes/fvwm-crystal
x11-wm/fvwm
xfce-base/xfce4-settings

Note also that for quite another number of packages you need the
unstable version, because quite often the stable version
(falsely) claims to require <python-3.12. These are at least
(for xfcbe-base, it is actually only one ebuild, but updating
this requires to have also the other updated or you might
experience runtime errors):

app-office/libreoffice
app-office/libreoffice-l10n
dev-cpp/libcmis
dev-libs/gobject-introspection-common
dev-libs/icu
dev-python/pygobject
dev-util/gdbus-codegen
mail-client/claws-mail
net-misc/networkmanager
sys-process/systemd-cron
x11-misc/redshift
xfce-base/exo
xfce-base/garcon
xfce-base/libxfce4ui
xfce-base/libxfce4util
xfce-base/libxfce4windowing
xfce-base/thunar
xfce-base/xfce4-appfinder
xfce-base/xfce4-panel
xfce-base/xfce4-session
xfce-base/xfconf
xfce-base/xfdesktop

[stefan11111]

Post by Martin Vaeth

Post by s***@shitposting.expert
I have done the migration to python 3.12.
The problem is that portage is pulling in python 3.11.

Many ebuilds have not been updated and pull in unnecessarily
python 3.11. If you use any of these packages, you need a patched
version of them in your overlay.
The list is not complete, even less if you have USE=python in
some packages.
The most notable package is www-client/firefox which is the only
one which actually *needs* <python-3.12 - the others just have
a broken dependency declaration.
app-crypt/gcr
app-portage/gverify
app-portage/mirrorselect
app-portage/overlint
app-text/iso-codes
dev-cpp/atkmm
dev-cpp/glibmm
dev-cpp/pangomm
dev-libs/glib
dev-libs/gobject-introspection
dev-libs/libevdev
dev-libs/libinput
dev-libs/jsoncpp
dev-libs/newt
dev-libs/zziplib
dev-python/ssl-fetch
dev-util/flawfinder
dev-util/intel_clc
gui-libs/gtk-layer-shell
gui-libs/vte-common
media-gfx/sane-backends
media-libs/avidemux-plugins
media-libs/fcft
media-libs/gegl
media-libs/graphene
media-libs/libaom
media-libs/libepoxy
media-libs/libglvnd
media-libs/libmypaint
media-libs/mesa
media-libs/opus
net-libs/libmbim
net-libs/nodejs
sys-apps/merge-usr
sys-boot/grub
sys-process/htop
www-client/firefox
x11-libs/vte
x11-themes/fvwm-crystal
x11-wm/fvwm
xfce-base/xfce4-settings
Note also that for quite another number of packages you need the
unstable version, because quite often the stable version
(falsely) claims to require <python-3.12. These are at least
(for xfcbe-base, it is actually only one ebuild, but updating
this requires to have also the other updated or you might
app-office/libreoffice
app-office/libreoffice-l10n
dev-cpp/libcmis
dev-libs/gobject-introspection-common
dev-libs/icu
dev-python/pygobject
dev-util/gdbus-codegen
mail-client/claws-mail
net-misc/networkmanager
sys-process/systemd-cron
x11-misc/redshift
xfce-base/exo
xfce-base/garcon
xfce-base/libxfce4ui
xfce-base/libxfce4util
xfce-base/libxfce4windowing
xfce-base/thunar
xfce-base/xfce4-appfinder
xfce-base/xfce4-panel
xfce-base/xfce4-session
xfce-base/xfconf
xfce-base/xfdesktop

Finally got to adding patched ebuilds to my overlay.
Everything works so far.
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-***@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"

[Martin Vaeth]

Post by stefan11111
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

[Arve Barsnes]

Post by Martin Vaeth

Post by stefan11111
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

The fix to stefan11111's problem is surely to extend the allowed
python versions in PYTHON_COMPAT though, the solution for that would
be different than changing the dependencies directly.

Regards,
Arve

[Martin Vaeth]

Post by Arve Barsnes

Post by Martin Vaeth

Post by stefan11111
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

The fix to stefan11111's problem is surely to extend the allowed
python versions in PYTHON_COMPAT though, the solution for that would
be different than changing the dependencies directly.

For the case that this was not clear: This is what I meant.
You would have a hard time to fix the dependencies in your
overlay "directly" in any other way than by editing the value
of PYTHON_COMPAT in the ebuild in your overlay.

However, this is only about *how* you modify the ebuild; my
point was that with current portage you *cannot avoid* to
modify the ebuild.

[stefan11111]

Post by Martin Vaeth

Post by stefan11111
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

Interesting read.
Would be nice is there was a way to set PYTHON_COMPAT through
envvars/make.conf vars like MYMESONARGS.
This seems like such an easy fix too. Just set PYTHON_COMPAT to include
python 3.12 and be done with it.
Another thing would be if adding dev-lang/python-3.11.7 to
package.provided only made portage pretend that
dev-lang/python-3.11.7 is installed, and not every version of python3.
Or if we had an easy way to patch ebuilds like we have
/etc/portage/patches...
I can't even make a dummy ebuild for python 3.11, since those ebuilds
won't use python 3.12 even
if it is installed if it isn't part of PYTHON_COMPAT(which is a
reasonable choice).

Anyway, at least I don't have many ebuilds to patch to support python
3.12.
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-***@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"

[Michael Orlitzky]

Post by stefan11111
Anyway, at least I don't have many ebuilds to patch to support python
3.12.

If you're comfortable with git, you could switch your ::gentoo repo to
a git checkout and edit/commit your changes there. Then when you git
pull/rebase, you'll find out about any merge conflicts.

[Martin Vaeth]

Post by stefan11111

Post by Martin Vaeth

Post by stefan11111
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

Interesting read.
Would be nice is there was a way to set PYTHON_COMPAT through
envvars/make.conf vars like MYMESONARGS.

This is not possible, the reason being implicitly explained
in the above bug:
PYTHON_COMPAT is used to calculate the dependencies from the
ebuild which are package metadata.

And this metadata must have been already calculated when
portage is started: if the ebuild would have to be interpreted
whenever the metadata is needed, portage would be unbearable
slow. Bot to speak about difficulties with things like tbz2
files which in general only contain the metadata and not
necessarily the ebuild anymore.

This is the reason why the emerge --regen and emerge -u ...
phases are practically disjoint (and why emerge --metadata
takes ages, in general, unless you use a repository with
already generated metadata).

Post by stefan11111
This seems like such an easy fix too. Just set PYTHON_COMPAT
to include python 3.12 and be done with it.

What you can do is the modify the corresponding eclass(es)
to auto-add python 3.12 to PYTHON_COMPAT.
After that change to take effect on the metadata, you have
to call emerge --regen for the main gentoo repository.
Note however, that - roughly speaking - this way you have
made your own "overlay" of the gentoo repository, and you
have to think of a way how to sync/merge your modification
with the gentoo repository regularly. At the very least,
you have to call the processor- and time-consuming
emerge --regen after every syncing.

Keeping some dozens packages in a "regular" overlay is
much simpler than practically maintaining all packages
in a local overlay...

Post by stefan11111
Another thing would be if adding dev-lang/python-3.11.7 to
package.provided only made portage pretend that
dev-lang/python-3.11.7 is installed, and not every version
of python3.

For portage, this trick would almost work, but portage would
resolve dependencies falsely and e.g. not recompile
packages which should be recompiled to work with
python:3.12.
Also, USE-dependencies with python versions
(e.g. python_targets_python3_11) could not be
resolved as you cannot package.provide USE-flags.

Moreover, even if the dependency problem could be solved,
the ebuilds would fail nevertheless if e.g. python-3.12 is
not in PYTHON_COPMPAT when it should be for several reasons:

1. The eclass would check whether the python:3.11 version is
present and use that for compilation.
2. The result would be put into the directory for the
python:3.11 version where python-3.12 does not find it.

Post by stefan11111
Or if we had an easy way to patch ebuilds like we have
/etc/portage/patches...

/etc/portage/patches can patch practically everything
in ebuilds *except metadata*. That's exactly what
bug 209653 is about.

[Martin Vaeth]

Post by Martin Vaeth
/etc/portage/patches can patch practically everything
in ebuilds *except metadata*. That's exactly what
bug 209653 is about.

Typo: I meant /etc/portage/env/*/*

[stefan11111]

Post by Martin Vaeth

Post by stefan11111

Post by Martin Vaeth

Post by stefan11111
This got me wondering though, is there no way to fix this globally
via make.conf instead of adding patched ebuilds to my overlay?

No. Until https://bugs.gentoo.org/209653 is fixed (which did not
happen since 16 years and presumably never will), there is no
other way to fix dependencies than to copy the ebuild to some
overlay.

Interesting read.
Would be nice is there was a way to set PYTHON_COMPAT through
envvars/make.conf vars like MYMESONARGS.

This is not possible, the reason being implicitly explained
PYTHON_COMPAT is used to calculate the dependencies from the
ebuild which are package metadata.
And this metadata must have been already calculated when
portage is started: if the ebuild would have to be interpreted
whenever the metadata is needed, portage would be unbearable
slow. Bot to speak about difficulties with things like tbz2
files which in general only contain the metadata and not
necessarily the ebuild anymore.
This is the reason why the emerge --regen and emerge -u ...
phases are practically disjoint (and why emerge --metadata
takes ages, in general, unless you use a repository with
already generated metadata).

Post by stefan11111
This seems like such an easy fix too. Just set PYTHON_COMPAT
to include python 3.12 and be done with it.

What you can do is the modify the corresponding eclass(es)
to auto-add python 3.12 to PYTHON_COMPAT.
After that change to take effect on the metadata, you have
to call emerge --regen for the main gentoo repository.
Note however, that - roughly speaking - this way you have
made your own "overlay" of the gentoo repository, and you
have to think of a way how to sync/merge your modification
with the gentoo repository regularly. At the very least,
you have to call the processor- and time-consuming
emerge --regen after every syncing.
Keeping some dozens packages in a "regular" overlay is
much simpler than practically maintaining all packages
in a local overlay...

Post by stefan11111
Another thing would be if adding dev-lang/python-3.11.7 to
package.provided only made portage pretend that
dev-lang/python-3.11.7 is installed, and not every version
of python3.

For portage, this trick would almost work, but portage would
resolve dependencies falsely and e.g. not recompile
packages which should be recompiled to work with
python:3.12.
Also, USE-dependencies with python versions
(e.g. python_targets_python3_11) could not be
resolved as you cannot package.provide USE-flags.
Moreover, even if the dependency problem could be solved,
the ebuilds would fail nevertheless if e.g. python-3.12 is
1. The eclass would check whether the python:3.11 version is
present and use that for compilation.
2. The result would be put into the directory for the
python:3.11 version where python-3.12 does not find it.

Post by stefan11111
Or if we had an easy way to patch ebuilds like we have
/etc/portage/patches...

/etc/portage/patches can patch practically everything
in ebuilds *except metadata*. That's exactly what
bug 209653 is about.

I see.
Should I at least file bugs about those packages?
Surely there is no reason to artificially limit the python version in
::gentoo?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-***@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"

[Michael Orlitzky]

Post by stefan11111
Should I at least file bugs about those packages?
Surely there is no reason to artificially limit the python version in
::gentoo?

Yes, especially if the package has a test suite that passes under
python-3.12. Most python packages are community-maintained and it
feels a lot safer bumping a package you aren't familiar with if it has
a passing test suite. But even an "it works" report is helpful.

[stefan11111]

Post by Michael Orlitzky

Post by stefan11111
Should I at least file bugs about those packages?
Surely there is no reason to artificially limit the python version in
::gentoo?

Yes, especially if the package has a test suite that passes under
python-3.12. Most python packages are community-maintained and it
feels a lot safer bumping a package you aren't familiar with if it has
a passing test suite. But even an "it works" report is helpful.

Ran the tests and filed a bug here:
https://bugs.gentoo.org/920933
Has the bug filing form changed?
I don't remember seeing that template when filing bugs.

I skipped dev-libs/glib because it requires dbus and fails with a linker
error when building it.

I tried adding -Wl,--unresolved-symbols=ignore-all and
-Wl,--warn-unresolved-symbols to my LDFLAGS,
both of which somehow made the compilation fail earlier.

Without those options, the compilation would fail with a linker error.
With those options the compilation failed much earlier with a compiler
error.
Can anyone explain why that happened?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-***@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"