29806 2014-02-05 06:55:48 +0400 i586-libgphoto2-devel should add i586-libexif-devel as a dependency 2020-11-04 15:45:34 +0300 1 1 4 Development Sisyphus libgphoto2-devel unstable x86_64 Linux CLOSED WORKSFORME P3 normal --- 38856 1 dmitry jinn aen cas dd glebfm jinn lav qa-sisyphus oldest_to_newest 145089 0 dmitry 2014-02-05 06:55:48 +0400 Обнаружилось, что 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 имеет аналогичный дефект в зависимостях. 156783 1 dmitry 2016-05-13 08:51:09 +0300 Эта проблема по прежнему присутствует и в P8. 165770 2 cas 2017-09-15 12:05:35 +0300 Выходит, сузешные зависимости вида pkgconfig(libexif) на arepo не распространяются. 165773 3 glebfm 2017-09-15 12:48:07 +0300 arepo вообще не предназначен для сборки пакетов. Только для того, чтобы устанавливать всякие блобы, которые уже собраны под ix86. Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. Например, в hasher-е. Как по мне, так это NOTABUG. 165774 4 glebfm 2017-09-15 12:49:08 +0300 s/сборки пакетов/сборки/ 165775 5 dmitry 2017-09-15 12:55:15 +0300 (In reply to comment #3) > arepo вообще не предназначен для сборки пакетов. Только для того, чтобы > устанавливать всякие блобы, которые уже собраны под ix86. > > Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. > Например, в hasher-е. > > Как по мне, так это NOTABUG. Почему разница в зависимостях идентичных 64 и 32-битных пакетов не баг? 165776 6 glebfm 2017-09-15 12:57:34 +0300 (In reply to comment #5) > Почему разница в зависимостях идентичных 64 и 32-битных пакетов не баг? Это arepo, а не 32-битный пакет. В 32-битном пакете всё хорошо. 165793 7 lav 2017-09-16 22:31:33 +0300 (В ответ на комментарий №3) > arepo вообще не предназначен для сборки пакетов. Только для того, чтобы > устанавливать всякие блобы, которые уже собраны под ix86. > > Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. > Например, в hasher-е. > > Как по мне, так это NOTABUG. Ответ не ясен. У нас нет multiarch и не будет? arepo это временный костыль для запуска сторонних бинарников? Хочу добавить, что в мире всё меньше дистрибутивов, у которых есть 32-битный вариант. По сути вопроса. Очень смешно предлагать разработчику собираться в hasher. Я чего-то не знаю, и все уже редактируют код и компилируют в хэшере? 165809 8 glebfm 2017-09-18 14:53:48 +0300 (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-е, конечно. 165814 9 dd 2017-09-18 16:23:36 +0300 Коллеги, мы так мило общаемся, но споры о терминах и бренности архитектур немножко наше продвижение замедляют. Понятно, что wine это вырожденный случай. Но devel-пакеты такие есть, а зависимостей нет. Если не сейчас, так в другой раз — мы опять и опять будем наступать на эти грабли в самый неподходящий момент. Глеб, чего сейчас не хватает, чтобы эти зависимости при сборке автоматически прописывались? 165820 10 jinn 2017-09-18 19:44:23 +0300 Коллеги, позвольте поинтересоваться. Архитектура x86_64-i586 не является самостоятельной и не может жить и работать без x86_64? Так зачем туда попадают devel-пакеты и смущают граждан? Или я совсем отстал от технологий и полноценная сборка и самостоятельная работа возможна? Поверхностный просмотр wiki не просветлил. 165852 11 glebfm 2017-09-20 13:51:10 +0300 (In reply to comment #10) > Коллеги, позвольте поинтересоваться. > Архитектура x86_64-i586 не является самостоятельной и не может жить и работать > без x86_64? Именно так, не является самостоятельной и предназначена для того, чтобы жить и работать только с x86_64. И запускать на x86_64 программы, [уже] собранные для x86. > Так зачем туда попадают devel-пакеты и смущают граждан? Пакеты в этот репозиторий попадают полностью автоматически по принципу, что лучше попадёт лишнее, а не оказывается, что что-то нужное не попало. 193766 12 lav 2020-11-04 15:45:34 +0300 (Ответ для 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