Отключить часть USE-флагов для abi_x86_32 - реально ли?

Собственно, задался вопросом - можно ли для 32-битных версий библиотек в multilib-системе сформировать свою цепочку зависимостей.

Чуть подробнее. Профили default/linux/amd64/* сейчас предлагают по умолчанию ABI_X86="64". Но тот же Skype, например, 32-битный, и требует наличия некоторых библиотек в 32-битной ипостаси. Также Wine имеет смысл собирать с abi_x86_32 ввиду 32-битности большинства windows-программ.

Таким образом, некоторые библиотеки нужны в 32-бит варианте помимо основного 64-битного. При этом они по зависимостям тянут ещё кучу других библиотек, причём зависимости формируются точно по таким же USE-флагам, что заданы в системе.

Вот у меня, например, для того же Skype и Wine (вроде ничего больше 32-битного нет) понадобилось 122 пакетам прописать в package.use флаг abi_x86_32. А ведь неплохо было бы для 32-бит версий программ чуть урезать аппетит по USE-флагам и сформировать своё, менее увесистое и раскидистое, дерево зависимостей.

Но насколько я понимаю, такой возможности в Portage нет. Или я ошибаюсь?

Или, может, такая возможность когда-нибудь в будущем появится, если она вообще теоретически возможна by design?

Вообще-то 32-битовые системы

Вообще-то 32-битовые системы практически умерли, так что вряд ли кто-нибудь будет заморачиваться на это...

А на разовую поделку можно быстренько на коленках скриптик сваять.

SysA написал(а): Вообще-то

SysA написал(а):
Вообще-то 32-битовые системы практически умерли

Skype 32-битный. Не умер, живёт, и скорее всего ещё долго будет жить.

Ага, как Ленин - вечно живой!

Ага, как Ленин - вечно живой! :D Слышали, знаем...

Для Линукса он умер - посмотри на текущую версию и политику M$.
К тому же я говорил о системах, а не о приложениях - полтора инвалида не делают погоды. Сейчас практически все дистры один за другим замораживают поддержку 32-битов, поскольку железо вымирает и никому эта тема неинтересна.

.)

Только страшно становится, что могут под эту лавочку появиться хотелки накодить только 64-разрядные программы. И что тогда с ними делать на устаревшем 32-х разрядном intel (хоть и старый, но живой)? А с arm? Их же 32-х разрядных навалом.

Linux был ценен более долгим сроком поддержки старого оборудования. Да, ядро туда собрать проблем нет, но было бы что на этом ядре запускать.

Мое личное наблюдение, не 32-й разрядный intel вымирает, а его вымирают. Да никто не будет ставить на новый комп старую операционку, но зачем linux-дистрибутивам отказывать своим пользователям в использовании их старого оборудования.

закономерный прогресс: ведь давно уже нет поддержки ХТ/АТ

Kevol написал(а):
Только страшно становится, что могут под эту лавочку появиться хотелки накодить только 64-разрядные программы. И что тогда с ними делать на устаревшем 32-х разрядном intel (хоть и старый, но живой)? А с arm? Их же 32-х разрядных навалом.

Это не "как страшно жить", а закономерный процесс: ведь давно уже нет поддержки ХТ/АТ (т.е. 8-битовых и 16-битовых) компов и никто не убивается по этому поводу. Вот и подходит время х86-32. И не надо спекулировать на АРМ'ах - это совсем другая песня и 32-битовые в основном на встроеных машинках, которые сами по себе весьма специализированные. А на серверах/десктопах те же 64 бита.

Kevol написал(а):
Linux был ценен более долгим сроком поддержки старого оборудования. Да, ядро туда собрать проблем нет, но было бы что на этом ядре запускать.

Так было пока разработчики по бедности массово сидели на 32-битовых машинах, а теперь ситуация изменилась, и они в основном на 64-х. А кому охота делать лишнию работу, к тому же которую не на чем протестировать, да и перспективы-то нет?!..

Kevol написал(а):
Мое личное наблюдение, не 32-й разрядный intel вымирает, а его вымирают. Да никто не будет ставить на новый комп старую операционку, но зачем linux-дистрибутивам отказывать своим пользователям в использовании их старого оборудования.

А в чем интерес разработчиков/майнтейнеров?! Почему они должны тратить свое время на ваше старое железо? Ведь репозитории не берутся из воздуха - кто-то же их должен собрать/протестировать. А лишняя ветка - это дополнительное время и ресурсы, как минимум. Вы же лично (как и все остальные) не поддерживаете своими финансами "так вам нужную" поддержку старья - вот и результат соответствующий...

.

На ARM не спекулирую. Давно появились 64-х разрядные? 32-х разрядных еще навалом, а устареть еще успели. Да, за 64-х разрядными будущее, но сегодняшнее еще представляет смесь. И, думаю, такое положение продержится еще не один год.

По проверке на x86 32-х разрядного бинарника достаточно ключика -m32. Ничего ни покупать, ни искать на помойке не придется. Вопрос был о тенденции по разработке без оглядки. (Пример - "нет linux без systemd" == "нет x86 без 64 бит,а не х86 архитектура используется всего в 2%")

ИМХО, вся проблема, изложенная в вопросе ТС, кроется в перпендикулярности abi_____ к понятию USE. Конечно, стоит с большой осторожностью вводить новые понятия в устоявшуюся концепцию, в данном случае, дистрибутив, но иногда без этого нового понятия совсем бардак получается. Вот так и будем жить под углом 45 к полу пока размерности не схлопнуться (исчезнет необходимость запускать еще одну abi). :)

Kevol написал(а): ...По

Kevol написал(а):
...По проверке на x86 32-х разрядного бинарника достаточно ключика -m32. Ничего ни покупать, ни искать на помойке не придется. Вопрос был о тенденции по разработке без оглядки. (Пример - "нет linux без systemd" == "нет x86 без 64 бит,а не х86 архитектура используется всего в 2%")...

Тут дело не в помойках, конечно, а основной вопрос в трудозатратах и стимуле. В опенсорсе обычно делается для себя и/или под что-то конкретное. Как я уже говорил, крайне редко кто-либо делает для сферического коня в вакууме. :)

.

Скорее есть главное конкурентное преимущество самой распространённой ОС в виде богатого наследия мутных 32-разрядных бинарников. И wine.

:wq
--
Live free or die

.)

Anarchist написал(а):
Скорее есть главное конкурентное преимущество самой распространённой ОС в виде богатого наследия мутных 32-разрядных бинарников. И wine.

Есть еще мутные нативные почти проприетарные программульки ... (отечественные) -> опять будут говорить: "Вот видите, с вашим линуксом одни проблемы. Дали же вам нативные бинарники, а вы опять плачитесь". Проблемы повсеместного отсутствия исходников - там где надо и не надо. А если есть исходники, то часто написаны программистами понимающими толк в x86_32, где по ходу пьесы точно определяется не только порядок байт, но и размер int, short, long.

А жить с этими программульками надо бы еще 5-10 лет.

sys-boot/grub:0 требует

sys-boot/grub:0 требует abi_x86_32

Working on Gentoo Linux for Asus P535 and Qtopia :-)

Он тоже в переспективе

Он тоже в переспективе умирает( так как 16 бит ) и на смену есть uefi

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): на смену

slepnoga написал(а):
на смену есть uefi

лучше бы и он умер, в пользу coreboot

интересная штука, не слышал

интересная штука,

не слышал еще о таком. Что нужно, чтобы установить ее на материнку ASUS P7H55, на сколько я понимаю coreboot устанавливается вместо bios. Я посмотрел список поддерживаемых материнок, но в списке их слишком мало.

когда он будет работать на

когда он будет работать на произвольно взятой матери,приходу,поговорим.

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): когда он

slepnoga написал(а):
когда он будет работать на произвольно взятой матери,приходу,поговорим.

да, windows-пользователи о линукс тоже так говорили лет 15-20 назад

Ну вот через 15-20 лет и

Ну вот через 15-20 лет и поговорим ;)

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): Он тоже

slepnoga написал(а):
Он тоже в переспективе умирает( так как 16 бит ) и на смену есть uefi

К сожалению на некоторых материнках UEFI настолько кривой, что лучше оставить Legacy включенным :)

Working on Gentoo Linux for Asus P535 and Qtopia :-)

Сам по себе - нет!

oleg_kaa написал(а):
sys-boot/grub:0 требует abi_x86_32

Сам по себе - нет, только по зависимостям!

sys-boot/grub-0.97-r16::gentoo  USE="ncurses -custom-cflags -netboot -static"

Скорее всего у тебя ncurses с поддержкой 32 битов.

Год назад уже была такая тема.

Я тогда задавал вопрос касательно wine прочих abi_x86_32
Там ответа на данный вопрос никто не дал.
На сегодня решения нет и приходится держать 170 пакетов в abi_x86_32. Это в основном библиотеки и системные приложения типа eudev и dbus.

По-моему, это и есть ответ. В

По-моему, это и есть ответ. В других своих комментариях здесь я объяснил/уточнил почему так...

В текущей реализации это

В текущей реализации это невозможно. На мой взгляд, данную проблему можно было бы решить разделением пакетов на разные ебилды для разных архитектур. Насколько эта реализация тродоемка - мне трудно оценить. Имхо, на эту тему лучше с разработчиками поговорить непосредственно.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".