USE-флаги в portage

Вряд ли.

cat /etc/portage/package.use/abix86 
x11-proto/xf86bigfontproto abi_x86_32
x11-proto/xextproto abi_x86_32
x11-libs/libX11 abi_x86_32
x11-proto/xcb-proto abi_x86_32
sys-libs/gpm abi_x86_32
dev-libs/libpthread-stubs abi_x86_32
x11-libs/libXau abi_x86_32
x11-proto/xproto abi_x86_32
x11-proto/inputproto abi_x86_32
x11-libs/libXext abi_x86_32
x11-proto/kbproto abi_x86_32
sys-libs/ncurses abi_x86_32
x11-libs/libXdmcp abi_x86_32
x11-libs/libxcb abi_x86_32

Предлагаю костыль:
Сделай в директории /etc/portage/package.use файлик с именем флага (например, abi_x86_32.use). В нём указывай пакеты _только_ с этим флагом

...
<=foo/bar-x.y.z abi_x86_32
  bla-bla/bla abi_x86_32
...

Так, стоять, если указывать руками ABI, это ж все равно не то, что хочет ТС.

так и делаю, точнее, у меня файл abi_x86_32.in с именами пакетов, а из него скриптом уже делаю настоящий. Костыльно это.

А что же он хочет?

Я так понимаю, он хочет различные юзы для разных abi. Так можно замутить свой сэт флагов через package.env, возможно есть какая-то возможность заставить использовать юзы, в зависимости от ABI?

ТС хочет формата типа такого

abi_x86_32 x11-proto/xf86bigfontproto x11-proto/xf86bigfontproto

или чего-то аналогичного. Т.е. не пары «атом»-«флаги», а «флаг»-«атомы».

У меня не сложилось такого впечатления от стартового поста. Но если это так, то, вероятно, нужно мутить свой eclass. В этом вопросе Pinkbyte может быть что-то прояснит.

Я так и понял. Но выглядит, как каша.

Ну мне тут намекают, что те самые сэты пакетов — это вообще странная сомнительной полезности и уровня поддержки фича, которую так и не реализовали до конца и уже собираются выкинуть, так что, вполне вероятно, это будет единственный способ. Но он кажется мне не столь удобным с точки зрения пользователя. Если ТС хочет исключительно то, что упомянуто в ОП, то это бессмысленно, да к тому же жутко неудобно, и, как мне кажется, в случае необходимости модификации перечня пакетов, указанных подобным образом, он поймёт свою ошибку.

Если ТС хочет исключительно то, что упомянуто в ОП, то это бессмысленно, да к тому же жутко неудобно, и, как мне кажется, в случае необходимости модификации перечня пакетов, указанных подобным образом, он поймёт свою ошибку.

Разделяю.

Ну мне тут намекают, что те самые сэты пакетов — это вообще странная сомнительной полезности и уровня поддержки фича, которую так и не реализовали до конца и уже собираются выкинуть

Если можно, подробнее. Где глянуть?

У меня для мультилиба в make.conf прописано вот что:

ABI_X86="64 32"

А можно ли portage задавать use-флаги в стиле «флаг» — «список пакетов»?

Не понял. Ты хочешь синтаксис

flag1 category1/package1
flag2 category2/package2

вместо

category1/package1 flag1
category2/package2 flag2

Нафига?

самые сэты пакетов — это вообще странная сомнительной полезности и уровня поддержки фича, которую так и не реализовали до конца и уже собираются выкинуть

Я так и не понял при чём тут сеты и package.env, но я не слышал о выкидывании поддержки ни того, ни другого. Более того, package.env с каждой версией portage всё расширяют и делают гибче.

По теме(генты в данную секунду под рукой нет) - надо курить man portage на то, какие переменные можно подменять в package.env. Если там можно менять USE-флаги, то чисто теоретически можно сделать глобальный враппер и написать там bash-скрипт, который будет перечисленному списку пакеты выставлять нужный флаг.

Но это как-то дико костыльно выглядит.

скорее, я хочу файл с названием юз-флага, в котором бы были перечислены пакеты, в которых он включен.

Причина — мультилиб.

Ну в том и суть, что над ней всё ещё работают и она готова не до конца, вот где-то тут об этом написано было https://wiki.gentoo.org/wiki/GLEP:21 довольно давно правда.

В любом случае, env, use и все прочие не работает с этими сэтами, то ли пока, то ли by design, но тогда синтаксис указания юзов в сетах выглядит странно. Кстати, кому жаловаться на сломанный udev в тестинге (sys-fs/udev-init-scripts-29)?

баг типа пофиксен

Не знаю, что там и где пофикшено, но со вчерашнего дня ничего не изменилось, ни один модуль ядра не загружается самостоятельно при загрузке (а блоб зелёных так вообще _опять_ не работает с последним релизным ядром, но это вряд ли связано).
В общем, хотелось бы выразить «благодарность» тому толстому чуваку, который потратил моё время и заставил сделать 3 перезагрузки локалхоста.

по этой причине я компы не перезагружаю и не выключаю.