совместимость paludis(cave) + multilib для иксов
В оверлее multilib в x11-libs/* часто встречаются ебилды, включающие в себя multilib-native eclass, как впрочем и в целом репозитории, и использующие при этом функцию xorg-2_pkg_setup(), полученную от eclass xorg-2.
При включении флага lib32 ни один из этих пакетов поставиться не смог. Посмотрев в /tmp, я обнаружил, что в рабочей директории ( ${PackageName}/work ) директории ${PackageName}_build_[x86,amd64] пусты. Очевидно, что нативные врапперы наложились на xorg-2_pgk_setup() по негативному сценарию с потерей функциональности.
В то же время, прочие библиотеки, не содержащие вызова xorg-2_pkg_setup(), поставились штатно. Отсюда я делаю вывод, о неисправности конкретной связки.
Возможно ошибка связана с использование палудиса, поскольку он не поддерживается eclass-debug.log и предупреждение об этом выводится каждый раз при сборке пакетов из multilib.
Прежде всего хотелось бы узнать о принципиальной совместимости палудиса и мультилиба, получалось ли у кого-нибудь заставить работать эту связку? Если были успешные попытки, то мне, возможно, смогут подсказать источник проблем. Если пока ни одной не удалось, можем попробовать вместе придумать самый простое решение-костыль.
- Для комментирования войдите или зарегистрируйтесь
Я локализовал первопричину
Я локализовал первопричину ошибок - неправильный порядок использования трансформеров. Чтобы multilib ебилды начали собираться, необходимо собюдать следующий порядок наследования eclass'ов: сначала все обычные, потом multilib-native, затем xorg-2
http://sprunge.us/AjAF?python
Вышеуказанным скриптом были поправлены ebuildы из x11-libs.
проблему я решил, но решение это не самое удобное: после каждого синка придётся заново прогонять скрипт. Я вижу несколько более правильных путей: можно попробовать написать хук, который будет конверитить ebuild на ходу, можно написать разработчикам мультилиба и попросить их заносить eclassы в правильном порядке вручную или прогнать через тот же самый примитивный скрипт.
Но ни в том, ни в другом я не уверен, и никогда я ничем подобным не занимался. Что подскажем мне коллективный разум?
коллективный разум скажет
коллективный разум скажет спросит " а с портаге оно работает" и в случае положительного ответа потеряет всяческий интерес к этому вопросу.
если ответ положительный - то ваш палдус неправильно поддерживает спецификацю PMS
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 ;)
вести с полей
Поскольку в названии топика спецефирован клиент paludis, то очевидно, что баг имеет место быть только в этом случае, но не во всех.
Портаге постоянно меняется. У него для этого появился такой костыль: debug-eclass.log, у палудиса эту функциональность ещё не прикрутили. Я не разработчик и не в курсе, существует ли такая возможность.
Быть может разработчики палудиса ещё не осознали зачем это нужно и стоит их потыкать, а может лучше попросить разработчиков мультилиба поддерживать и нестандартный клиент, если это так дешёво стоит.
Поскольку здешний коллективный разум потерял всякий интерес, пойду поищу другой, не может того быть, чтобы палудис никем не использовался.
P.S. против портежа у меня только одна претензия: хреновая работа с оверлеями
.
Конечно, используется. Но без multilib
Мы тоже не всего читали Шнитке!.. © В. Вишневский