Обнаружилось, что configure из wine не может найти libgphoto2, при этом 'configure --enable-win64' его находит. Как оказалось, проблема была вызвана тем, что не был установлен i586-libexif-devel-0.6.21-alt1. $ uname -r 3.10.28-std-def-alt1 $ rpm -qa | grep gphoto2 libgphoto2-devel-2.5.2-alt1 i586-libsane-gphoto2-1.0.24-alt2.2 i586-libgphoto2-2.5.2-alt1 libgphoto2-2.5.2-alt1 libsane-gphoto2-1.0.24-alt2.2 i586-libgphoto2-devel-2.5.2-alt1 $ rpm -qR libgphoto2-devel-2.5.2-alt1 libgphoto2 = 2.5.2-alt1 /bin/sh /usr/lib64/pkgconfig coreutils pkgconfig(libexif) >= 0.6.13 rpmlib(PayloadIsLzma) $ rpm -qR i586-libgphoto2-devel-2.5.2-alt1 libgphoto2-devel = 2.5.2-alt1 i586-libgphoto2 = 2.5.2-alt1 rpmlib(PayloadIsLzma) i586-libgphoto2_2.4-devel имеет аналогичный дефект в зависимостях.
Эта проблема по прежнему присутствует и в P8.
Выходит, сузешные зависимости вида pkgconfig(libexif) на arepo не распространяются.
arepo вообще не предназначен для сборки пакетов. Только для того, чтобы устанавливать всякие блобы, которые уже собраны под ix86. Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. Например, в hasher-е. Как по мне, так это NOTABUG.
s/сборки пакетов/сборки/
(In reply to comment #3) > arepo вообще не предназначен для сборки пакетов. Только для того, чтобы > устанавливать всякие блобы, которые уже собраны под ix86. > > Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. > Например, в hasher-е. > > Как по мне, так это NOTABUG. Почему разница в зависимостях идентичных 64 и 32-битных пакетов не баг?
(In reply to comment #5) > Почему разница в зависимостях идентичных 64 и 32-битных пакетов не баг? Это arepo, а не 32-битный пакет. В 32-битном пакете всё хорошо.
(В ответ на комментарий №3) > arepo вообще не предназначен для сборки пакетов. Только для того, чтобы > устанавливать всякие блобы, которые уже собраны под ix86. > > Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. > Например, в hasher-е. > > Как по мне, так это NOTABUG. Ответ не ясен. У нас нет multiarch и не будет? arepo это временный костыль для запуска сторонних бинарников? Хочу добавить, что в мире всё меньше дистрибутивов, у которых есть 32-битный вариант. По сути вопроса. Очень смешно предлагать разработчику собираться в hasher. Я чего-то не знаю, и все уже редактируют код и компилируют в хэшере?
(In reply to comment #7) > (В ответ на комментарий №3) > > arepo вообще не предназначен для сборки пакетов. Только для того, чтобы > > устанавливать всякие блобы, которые уже собраны под ix86. > > > > Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. > > Например, в hasher-е. > > > > Как по мне, так это NOTABUG. > Ответ не ясен. У нас нет multiarch и не будет? https://wiki.debian.org/Multiarch "Multiarch is the term being used to refer to the capability of a system to install and run applications of multiple different binary targets on the same system." Есть -- install и run ваши бинарники. > arepo это временный костыль для > запуска сторонних бинарников? Да, но он такой же временный, как и сами бинарники. > Хочу добавить, что в мире всё меньше дистрибутивов, у которых есть 32-битный > вариант. Да, дистрибутивы под эту архитектуру уже никому не нужны. > По сути вопроса. > Очень смешно предлагать разработчику собираться в hasher. Ха-ха. А что смешного? > Я чего-то не знаю, и все уже редактируют код и компилируют в хэшере? Редактируют не знаю в чём, а собирают уже точно в docker-е. Лучше бы в hasher-е, конечно.
Коллеги, мы так мило общаемся, но споры о терминах и бренности архитектур немножко наше продвижение замедляют. Понятно, что wine это вырожденный случай. Но devel-пакеты такие есть, а зависимостей нет. Если не сейчас, так в другой раз — мы опять и опять будем наступать на эти грабли в самый неподходящий момент. Глеб, чего сейчас не хватает, чтобы эти зависимости при сборке автоматически прописывались?
Коллеги, позвольте поинтересоваться. Архитектура x86_64-i586 не является самостоятельной и не может жить и работать без x86_64? Так зачем туда попадают devel-пакеты и смущают граждан? Или я совсем отстал от технологий и полноценная сборка и самостоятельная работа возможна? Поверхностный просмотр wiki не просветлил.
(In reply to comment #10) > Коллеги, позвольте поинтересоваться. > Архитектура x86_64-i586 не является самостоятельной и не может жить и работать > без x86_64? Именно так, не является самостоятельной и предназначена для того, чтобы жить и работать только с x86_64. И запускать на x86_64 программы, [уже] собранные для x86. > Так зачем туда попадают devel-пакеты и смущают граждан? Пакеты в этот репозиторий попадают полностью автоматически по принципу, что лучше попадёт лишнее, а не оказывается, что что-то нужное не попало.
(Ответ для Gleb F-Malinovskiy на комментарий #8) > (In reply to comment #7) > > (В ответ на комментарий №3) > > > arepo вообще не предназначен для сборки пакетов. Только для того, чтобы > > > устанавливать всякие блобы, которые уже собраны под ix86. > > > > > > Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. > > > Например, в hasher-е. > > > > > > Как по мне, так это NOTABUG. > > Ответ не ясен. У нас нет multiarch и не будет? > https://wiki.debian.org/Multiarch > "Multiarch is the term being used to refer to the capability of a system to > install and run applications of multiple different binary targets on the > same system." > Есть -- install и run ваши бинарники. Там же: The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. > > > arepo это временный костыль для > > запуска сторонних бинарников? > Да, но он такой же временный, как и сами бинарники. > > > Хочу добавить, что в мире всё меньше дистрибутивов, у которых есть 32-битный > > вариант. > Да, дистрибутивы под эту архитектуру уже никому не нужны. По этой теме всё очень просто. Поддержка сборки 32-битных программ в 64-битной системе нужна в таком объёме, чтобы можно было собрать wine, и обсуждать тут особо нечего. Это такое де-факто. На данный момент в Сизифе нет зависимости libgphoto2-devel от libexif-devel, поэтому заявленная проблема в любом случае не актуальна: $ rpm -q --requires libgphoto2-devel libgphoto2-6 = 2.5.26-alt1:sisyphus+259921.200.1.1 $ rpm -q --requires i586-libgphoto2-devel libgphoto2-devel = 2.5.26-alt1:sisyphus+259921.200.1.1 i586-libgphoto2-6 = 2.5.26-alt1:sisyphus+259921.200.1.1