Bug 29806 - i586-libgphoto2-devel should add i586-libexif-devel as a dependency
Summary: i586-libgphoto2-devel should add i586-libexif-devel as a dependency
Status: CLOSED WORKSFORME
Alias: None
Product: Sisyphus
Classification: Development
Component: libgphoto2-devel (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P3 normal
Assignee: Dmitriy Khanzhin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on: 38856
Blocks:
  Show dependency tree
 
Reported: 2014-02-05 06:55 MSK by Dmitry Timoshkov
Modified: 2020-11-04 15:45 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Timoshkov 2014-02-05 06:55:48 MSK
Обнаружилось, что 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 имеет аналогичный дефект в зависимостях.
Comment 1 Dmitry Timoshkov 2016-05-13 08:51:09 MSK
Эта проблема по прежнему присутствует и в P8.
Comment 2 Andrey Cherepanov 2017-09-15 12:05:35 MSK
Выходит, сузешные зависимости вида pkgconfig(libexif) на arepo не распространяются.
Comment 3 Gleb F-Malinovskiy 2017-09-15 12:48:07 MSK
arepo вообще не предназначен для сборки пакетов.  Только для того, чтобы устанавливать всякие блобы, которые уже собраны под ix86.

Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе.  Например, в hasher-е.

Как по мне, так это NOTABUG.
Comment 4 Gleb F-Malinovskiy 2017-09-15 12:49:08 MSK
s/сборки пакетов/сборки/
Comment 5 Dmitry Timoshkov 2017-09-15 12:55:15 MSK
(In reply to comment #3)
> arepo вообще не предназначен для сборки пакетов.  Только для того, чтобы
> устанавливать всякие блобы, которые уже собраны под ix86.
> 
> Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. 
> Например, в hasher-е.
> 
> Как по мне, так это NOTABUG.

Почему разница в зависимостях идентичных 64 и 32-битных пакетов не баг?
Comment 6 Gleb F-Malinovskiy 2017-09-15 12:57:34 MSK
(In reply to comment #5)
> Почему разница в зависимостях идентичных 64 и 32-битных пакетов не баг?

Это arepo, а не 32-битный пакет.
В 32-битном пакете всё хорошо.
Comment 7 Vitaly Lipatov 2017-09-16 22:31:33 MSK
(В ответ на комментарий №3)
> arepo вообще не предназначен для сборки пакетов.  Только для того, чтобы
> устанавливать всякие блобы, которые уже собраны под ix86.
> 
> Если вы хотите собрать 32-битный бинарник, соберите его в 32-битной системе. 
> Например, в hasher-е.
> 
> Как по мне, так это NOTABUG.
Ответ не ясен. У нас нет multiarch и не будет? arepo это временный костыль для запуска сторонних бинарников?

Хочу добавить, что в мире всё меньше дистрибутивов, у которых есть 32-битный вариант.
По сути вопроса. Очень смешно предлагать разработчику собираться в hasher. Я чего-то не знаю, и все уже редактируют код и компилируют в хэшере?
Comment 8 Gleb F-Malinovskiy 2017-09-18 14:53:48 MSK
(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-е, конечно.
Comment 9 Дмитрий Державин 2017-09-18 16:23:36 MSK
Коллеги, мы так мило общаемся, но споры о терминах и бренности архитектур немножко наше продвижение замедляют. Понятно, что wine это вырожденный случай. Но devel-пакеты такие есть, а зависимостей нет. Если не сейчас, так в другой раз — мы опять и опять будем наступать на эти грабли в самый неподходящий момент.

Глеб, чего сейчас не хватает, чтобы эти зависимости при сборке автоматически прописывались?
Comment 10 Dmitriy Khanzhin 2017-09-18 19:44:23 MSK
Коллеги, позвольте поинтересоваться.
Архитектура x86_64-i586 не является самостоятельной и не может жить и работать
без x86_64? Так зачем туда попадают devel-пакеты и смущают граждан?
Или я совсем отстал от технологий и полноценная сборка и самостоятельная
работа возможна?
Поверхностный просмотр wiki не просветлил.
Comment 11 Gleb F-Malinovskiy 2017-09-20 13:51:10 MSK
(In reply to comment #10)
> Коллеги, позвольте поинтересоваться.
> Архитектура x86_64-i586 не является самостоятельной и не может жить и работать
> без x86_64?
Именно так, не является самостоятельной и предназначена для того, чтобы жить и работать только с x86_64.  И запускать на x86_64 программы, [уже] собранные для x86.

> Так зачем туда попадают devel-пакеты и смущают граждан?
Пакеты в этот репозиторий попадают полностью автоматически по принципу, что лучше попадёт лишнее, а не оказывается, что что-то нужное не попало.
Comment 12 Vitaly Lipatov 2020-11-04 15:45:34 MSK
(Ответ для 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