Отключить часть 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 написал(а): Вообще-то
Skype 32-битный. Не умер, живёт, и скорее всего ещё долго будет жить.
Ага, как Ленин - вечно живой!
Ага, как Ленин - вечно живой! :D Слышали, знаем...
Для Линукса он умер - посмотри на текущую версию и политику M$.
К тому же я говорил о системах, а не о приложениях - полтора инвалида не делают погоды. Сейчас практически все дистры один за другим замораживают поддержку 32-битов, поскольку железо вымирает и никому эта тема неинтересна.
.)
Только страшно становится, что могут под эту лавочку появиться хотелки накодить только 64-разрядные программы. И что тогда с ними делать на устаревшем 32-х разрядном intel (хоть и старый, но живой)? А с arm? Их же 32-х разрядных навалом.
Linux был ценен более долгим сроком поддержки старого оборудования. Да, ядро туда собрать проблем нет, но было бы что на этом ядре запускать.
Мое личное наблюдение, не 32-й разрядный intel вымирает, а его вымирают. Да никто не будет ставить на новый комп старую операционку, но зачем linux-дистрибутивам отказывать своим пользователям в использовании их старого оборудования.
закономерный прогресс: ведь давно уже нет поддержки ХТ/АТ
Это не "как страшно жить", а закономерный процесс: ведь давно уже нет поддержки ХТ/АТ (т.е. 8-битовых и 16-битовых) компов и никто не убивается по этому поводу. Вот и подходит время х86-32. И не надо спекулировать на АРМ'ах - это совсем другая песня и 32-битовые в основном на встроеных машинках, которые сами по себе весьма специализированные. А на серверах/десктопах те же 64 бита.
Так было пока разработчики по бедности массово сидели на 32-битовых машинах, а теперь ситуация изменилась, и они в основном на 64-х. А кому охота делать лишнию работу, к тому же которую не на чем протестировать, да и перспективы-то нет?!..
А в чем интерес разработчиков/майнтейнеров?! Почему они должны тратить свое время на ваше старое железо? Ведь репозитории не берутся из воздуха - кто-то же их должен собрать/протестировать. А лишняя ветка - это дополнительное время и ресурсы, как минимум. Вы же лично (как и все остальные) не поддерживаете своими финансами "так вам нужную" поддержку старья - вот и результат соответствующий...
.
На ARM не спекулирую. Давно появились 64-х разрядные? 32-х разрядных еще навалом, а устареть еще успели. Да, за 64-х разрядными будущее, но сегодняшнее еще представляет смесь. И, думаю, такое положение продержится еще не один год.
По проверке на x86 32-х разрядного бинарника достаточно ключика -m32. Ничего ни покупать, ни искать на помойке не придется. Вопрос был о тенденции по разработке без оглядки. (Пример - "нет linux без systemd" == "нет x86 без 64 бит,а не х86 архитектура используется всего в 2%")
ИМХО, вся проблема, изложенная в вопросе ТС, кроется в перпендикулярности abi_____ к понятию USE. Конечно, стоит с большой осторожностью вводить новые понятия в устоявшуюся концепцию, в данном случае, дистрибутив, но иногда без этого нового понятия совсем бардак получается. Вот так и будем жить под углом 45 к полу пока размерности не схлопнуться (исчезнет необходимость запускать еще одну abi). :)
Kevol написал(а): ...По
Тут дело не в помойках, конечно, а основной вопрос в трудозатратах и стимуле. В опенсорсе обычно делается для себя и/или под что-то конкретное. Как я уже говорил, крайне редко кто-либо делает для
сферического коня в вакууме. :).
Скорее есть главное конкурентное преимущество самой распространённой ОС в виде богатого наследия мутных 32-разрядных бинарников. И wine.
:wq
--
Live free or die
.)
Есть еще мутные нативные почти проприетарные программульки ... (отечественные) -> опять будут говорить: "Вот видите, с вашим линуксом одни проблемы. Дали же вам нативные бинарники, а вы опять плачитесь". Проблемы повсеместного отсутствия исходников - там где надо и не надо. А если есть исходники, то часто написаны программистами понимающими толк в 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 написал(а): на смену
лучше бы и он умер, в пользу 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 написал(а): когда он
да, 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 написал(а): Он тоже
К сожалению на некоторых материнках UEFI настолько кривой, что лучше оставить Legacy включенным :)
Working on Gentoo Linux for Asus P535 and Qtopia :-)
Сам по себе - нет!
Сам по себе - нет, только по зависимостям!
Скорее всего у тебя
ncursesс поддержкой 32 битов.Год назад уже была такая тема.
Я тогда задавал вопрос касательно wine прочих abi_x86_32
Там ответа на данный вопрос никто не дал.
На сегодня решения нет и приходится держать 170 пакетов в abi_x86_32. Это в основном библиотеки и системные приложения типа eudev и dbus.
По-моему, это и есть ответ. В
По-моему, это и есть ответ. В других своих комментариях здесь я объяснил/уточнил почему так...
В текущей реализации это
В текущей реализации это невозможно. На мой взгляд, данную проблему можно было бы решить разделением пакетов на разные ебилды для разных архитектур. Насколько эта реализация тродоемка - мне трудно оценить. Имхо, на эту тему лучше с разработчиками поговорить непосредственно.