Сломанные зависимости

vvpnet · Сообщение **vvpnet** » 06 июл 2020, 07:10

Привет всем, потребовалось собрать и запустить ПО i586 под x86_64 архитектурой, неставятся нужные пакеты: libqt-dev.i586 и libfreetype6-dev.i586. Создается впячетление, что весь репозиторий i586 сломан.

Zeffanyx · Сообщение **Zeffanyx** » 06 июл 2020, 17:00

vvpnet писал(а): 06 июл 2020, 07:10 Привет всем, потребовалось собрать и запустить ПО i586 под x86_64 архитектурой, неставятся нужные пакеты: libqt-dev.i586 и libfreetype6-dev.i586. Создается впячетление, что весь репозиторий i586 сломан.

Всё правильно. Если вы собираете из исходного кода, то под 64-битной системой у вас выйдет 64-битная сборка. Если вам нужна 32-битная сборка, то лучше поставить 32-битную виртуальную машину и собрать под ней, либо собрать на ABF для i586.

Сообщение **VictorR2007** » 06 июл 2020, 19:59

Zeffanyx писал(а): 06 июл 2020, 17:00 либо собрать на ABF для i586

Или же с помощью mock-urpm, на котором не важно, какую архитектуру собирать.

vvpnet · Сообщение **vvpnet** » 07 июл 2020, 07:13

Zeffanyx писал(а): 06 июл 2020, 17:00
vvpnet писал(а): 06 июл 2020, 07:10 Привет всем, потребовалось собрать и запустить ПО i586 под x86_64 архитектурой, неставятся нужные пакеты: libqt-dev.i586 и libfreetype6-dev.i586. Создается впячетление, что весь репозиторий i586 сломан.
Всё правильно. Если вы собираете из исходного кода, то под 64-битной системой у вас выйдет 64-битная сборка. Если вам нужна 32-битная сборка, то лучше поставить 32-битную виртуальную машину и собрать под ней, либо собрать на ABF для i586.

Я совершенно с этим не согласен. Имею права собирать c ключем -platform linux-g++-32 и запускать их под ОС 64 бит, если имеются все необходимые 32х битные библиотеки. Это прекрасно работает на Альте, Ubuntu, Debian и т.д... где это только не практиковал. Дело даже не в сборке, а в запуске 32х битных приложений, которые нельзя запустить, из-за того, что нельзя поставить нужную либу, потому что репозиторий сломан. Это проблема репозитория а не разрядности

Zeffanyx · Сообщение **Zeffanyx** » 07 июл 2020, 15:38

vvpnet писал(а): 07 июл 2020, 07:13 Дело даже не в сборке, а в запуске 32х битных приложений, которые нельзя запустить, из-за того, что нельзя поставить нужную либу, потому что репозиторий сломан.

Можно пример 32-битной программы, которая не запускается в 64-битной Рсое?

vvpnet · Сообщение **vvpnet** » 08 июл 2020, 10:57

Zeffanyx писал(а): 07 июл 2020, 15:38
vvpnet писал(а): 07 июл 2020, 07:13 Дело даже не в сборке, а в запуске 32х битных приложений, которые нельзя запустить, из-за того, что нельзя поставить нужную либу, потому что репозиторий сломан.
Можно пример 32-битной программы, которая не запускается в 64-битной Рсое?

Речь идет о коммерческом отечественном ПО, я не могу вам его дать. Это ПО собирается под 64 бит архитектуру, но не работает. Одна из причин это передача указателей, через тип int (не спрашивайте меня, почему так сделано это наследие) и множество других интересных штук оперяющихся на 4х байтовые указатели. Так что, оно прекрасно чувствует себя под х32 но совершенно не пригодно под 64 бит.

Вот поэтому нужны либы х32 бита и нужна ОЗУ более 4х гигов. Pae - технология нам не подходит по ряду других причин.

Zeffanyx · Сообщение **Zeffanyx** » 08 июл 2020, 11:02

vvpnet писал(а): 08 июл 2020, 10:57 Вот поэтому нужны либы х32 бита и нужна ОЗУ более 4х гигов. Pae - технология нам не подходит по ряду других причин.

либы х32 и сборка под х32 - это совсем разные вещи. 32-битные программы в 64-битной Росе всю жизнь нормально работали. Wine, Softmaker Office, ранее - скайп.

vvpnet · Сообщение **vvpnet** » 08 июл 2020, 12:21

Zeffanyx писал(а): 08 июл 2020, 11:02
vvpnet писал(а): 08 июл 2020, 10:57 Вот поэтому нужны либы х32 бита и нужна ОЗУ более 4х гигов. Pae - технология нам не подходит по ряду других причин.
либы х32 и сборка под х32 - это совсем разные вещи. 32-битные программы в 64-битной Росе всю жизнь нормально работали. Wine, Softmaker Office, ранее - скайп.

Все верно так и должно быть, просто их элементарно поставить с репо нельзя из-за сломоных зависимостей

Zeffanyx · Сообщение **Zeffanyx** » 08 июл 2020, 15:47

vvpnet писал(а): 08 июл 2020, 12:21 Все верно так и должно быть, просто их элементарно поставить с репо нельзя из-за сломоных зависимостей

Репозитории у Росы конечно кривые, но всё же у вас очень специфический случай. Могу себе представить качество кода, не позволяющее нормально собирать под х86_64...

vvpnet · Сообщение **vvpnet** » 09 июл 2020, 05:14

Zeffanyx писал(а): 08 июл 2020, 15:47
vvpnet писал(а): 08 июл 2020, 12:21 Все верно так и должно быть, просто их элементарно поставить с репо нельзя из-за сломоных зависимостей
Репозитории у Росы конечно кривые, но всё же у вас очень специфический случай. Могу себе представить качество кода, не позволяющее нормально собирать под х86_64...

Не вижу не чего специфического, я просто хотел установить пакет который доступен в репозиторий. Вот сейчас прям прилитело обновление и вот такое уже сразу) Наверное это из-за wine32 где у меня все настроено для запуска некторого ПО Win.

В R8/8.1 таких ситуаций было минимум, мы по сей день на ней сидим, если это позволяет оборудование, если бы не запросили обновление ядра так бы и сидели. Там все есть, все устраевает, все надежно работает.

Zeffanyx · Сообщение **Zeffanyx** » 09 июл 2020, 11:06

Если старый пакет lib64spirv-tools удалить, то новый устанавливается без проблем.

vea · Сообщение **vea** » 09 июл 2020, 14:28

Вы считаете, что это нормально: удалять ручками какие-то пакеты перед обновлением? А может, все же, это должно предусматриваться в автоматическом режиме?

Zeffanyx · Сообщение **Zeffanyx** » 10 июл 2020, 16:46

vea писал(а): 09 июл 2020, 14:28 Вы считаете, что это нормально: удалять ручками какие-то пакеты перед обновлением? А может, все же, это должно предусматриваться в автоматическом режиме?

Я не считаю это нормальным. Качество репозиториев, как и следование довольно специфичным политикам сборки в Росе — весьма среднее. Тем не менее, если что-то надо сделать, то как правило есть варианты.

artemmen · Сообщение **artemmen** » 12 июл 2020, 17:48

urpmi --auto-update --replacefiles вроде сработало