Bug 39033

Удаление libX11 из hasher, куда был установлен php7-imagick:

# apt-get remove libX11
Reading Package Lists...
Building Dependency Tree...
The following packages will be REMOVED:
  libEGL libEGL-mesa libGL libGLX libGLX-mesa libImageMagick6.6 libX11 libXcomposite libXcursor libXdamage libXext libXfixes libXft libXi libXinerama libXpm libXrandr libXrender libXt libXxf86vm libcairo libgd3 libgraphviz libgtk+2 liblasi libpango
  librsvg php7-imagick
0 upgraded, 0 newly installed, 28 removed and 0 not upgraded.
Need to get 0B of archives.
After unpacking 30.3MB disk space will be freed.

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

(Ответ для Anton Farygin на комментарий #2)
> к сожалению, невозможно технически сделать конфликтующие библиотеки,
> предоставляющие одинаковый интерфейс.
Не очень понял, в чём проблема. Просто собирается несколько вариантов библиотеки с разными параметрами и пакуется в разные пакеты. Конфликтующими будут не библиотеки, а пакеты с ними, и можно будет выбрать, какой устанавливать.

Т.е. - клиентов тоже собирать несколько вариантов ?
Я подумаю над этой идеей.

посмотрел внимательнее, пока не придумал способа собрать параллельно библиотеку так, что бы её имя было каким-то другим. 

В других дистрибутивах предполагаемой схемы упаковки тоже не реализовано и, как правило, все собирают с иксами. Думаю, что оптимально было бы уговорить на такой функционал апстрим.

Задача просматривается такая - возможность одновременной работы и установки в системе библиотек ImageMagick, слинкованных с X11 и без.

Добавить флаг для сборки без иксов можно, как предложено в задании 260912, но большого смысла не видно - всех клиентов этой библиотеки придётся пересобирать для сборки в таком варианте.

(Ответ для Anton Farygin на комментарий #5)
> посмотрел внимательнее, пока не придумал способа собрать параллельно
> библиотеку так, что бы её имя было каким-то другим. 
> 
> В других дистрибутивах предполагаемой схемы упаковки тоже не реализовано и,
> как правило, все собирают с иксами. Думаю, что оптимально было бы уговорить
> на такой функционал апстрим.
Им недостаёт там самой малости: загрузки libX11 через dl. Я не смотрел код, может быть они уже и сделали.

> Задача просматривается такая - возможность одновременной работы и установки
> в системе библиотек ImageMagick, слинкованных с X11 и без.
Нужна возможность одновременной сборки, а потом установки одного из вариантов.

> Добавить флаг для сборки без иксов можно, как предложено в задании 260912,
> но большого смысла не видно - всех клиентов этой библиотеки придётся
> пересобирать для сборки в таком варианте.
Я поясню, в чём заблуждение: ABI библиотеки не меняется от того, собрана она с -with-x или без.
Поэтому страдать о пересборке не нужно.

Одновременное существование libImageMagick с разными опциями сборки в составе репозитория приведёт к непредсказуемому результату при попытке поставить пакет 'libMagickCore-6.Q16.so.6()(64bit)'.

(Ответ для Anton Farygin на комментарий #7)
> Одновременное существование libImageMagick с разными опциями сборки в
> составе репозитория приведёт к непредсказуемому результату при попытке
> поставить пакет 'libMagickCore-6.Q16.so.6()(64bit)'.
Это глупость, результат будет предсказуем: будет установлен пакет с такой библиотекой.
Если кому-то нужен более конкретный пакет, он может указать зависимость на пакет, а не на библиотеку.

нет, к сожалению обсуждение в devel идёт по правильному пути и да, результат будет действительно не предсказуем.

Если бы у таких пакетов, провайдящих разные библиотеки, можно было задавать веса для автоматического выбора, то можно было бы попробовать.

и сравнение abi Дима правильно предлагает сделать.

(Ответ для Anton Farygin на комментарий #9)
> нет, к сожалению обсуждение в devel идёт по правильному пути и да, результат
> будет действительно не предсказуем.
Ну тебе остаётся выбор:
- забыть про эту багу
- убрать @everybody из ACL
- ждать пакета ImageMagick с другим названием

Я пока что снял everybody с пакета, что бы не возникло лишних вопросов, хотя последнее твоё изменения меня в принципе устраивает и его можно выложить.

Не могу пройти мимо: разве наличие libX11 на сервере -- это такая большая проблема? 4 дополнительные библиотеки, суммарный размер которых -- 3.3 МБ.

$ rpm -qR libX11 
filesystem > 2.3.1-alt1:z
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.26)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libxcb.so.1()(64bit) >= set:ni0Q79T9m8c8LtIHEZvE2to7CMOpYYJtPQlu1To9g36rmZ7fk1
rpmlib(SetVersions)
rtld(GNU_HASH)
libX11-locales = 3:1.6.12-alt1:sisyphus+256796.100.1.1
rpmlib(PayloadIsLzma)


$ rpm -qR libX11-locales 
rpmlib(PayloadIsLzma)

]$ rpm -qR libxcb
libXau.so.6()(64bit) >= set:ge34k81
rpmlib(SetVersions)
libXdmcp.so.6()(64bit) >= set:jiOzo
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
rtld(GNU_HASH)
rpmlib(PayloadIsLzma)

$ rpm -qR libXau 
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
rtld(GNU_HASH)
rpmlib(PayloadIsLzma)

$ rpm -qR libXdmcp
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.25)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
rtld(GNU_HASH)
rpmlib(PayloadIsLzma)

(Ответ для Vitaly Lipatov на комментарий #0)
...
> Оставлю здесь некоторые пакеты, которые собираются с ImageMagick а потом
> ставятся на сервер, и X11 им там никаким боком:
> freeswitch	libImageMagick-devel	6.9.11.28-alt1
> gem-rmagick	libImageMagick-devel	6.9.11.28-alt1
> pfstools	libImageMagick-devel	6.9.11.28-alt1
> php7-imagick	libImageMagick-devel	6.9.11.28-alt1
> pstoedit	libImageMagick-devel	6.9.11.28-alt1
> python3-module-pythonmagick	libImageMagick-devel	6.9.11.28-alt1
> vips	libImageMagick-devel	6.9.11.28-alt1

По собранным пакетам список отличается:
$ epm wd libImageMagick6.6
 $ apt-cache whatdepends libImageMagick6.6
...
  transcode-1.1.7-alt13:sisyphus+250140.2400.12.1@1587564842
  php7-imagick-7.4.12-alt1.3:sisyphus+260638.5100.8.2@1604421253
  libvips-8.10.2-alt1:sisyphus+259804.100.1.1@1602537884
  converseen-0.9.8.1-alt1:sisyphus+251980.200.2.1@1589963931
  ale-0.9.0.3-alt9@1527707468

$ epm wd libImageMagick++6.8
 $ apt-cache whatdepends libImageMagick++6.8
..
python3-module-pythonmagick-0.9.64-alt3:sisyphus+256956.10100.14.2@1599545680
libpstoedit-3.70-alt4@1527708083
pfstools-2.1.0-alt4.1:sisyphus+249867.2600.11.2@1587505178
converseen-0.9.8.1-alt1:sisyphus+251980.200.2.1@1589963931
cuneiform-1.1.0-alt4:sisyphus+226682.100.2.3@1554596896


Получается, что кто-то просто так требует libImageMagick-devel при сборке.
Например, во freeswitch он используется только при сборке модуля mod_imagick, который изначально при добавлении выключен:

commit ecab16ed88e702a909700157948c19183aab119f
Author: Seven Du <dujinfang@gmail.com>
Date:   Fri Apr 10 20:40:24 2015 +0800

    FS-7516: add mod_imagick

+++ b/build/modules.conf.in
...
+#formats/mod_imagick

(Ответ для Vladimir D. Seleznev на комментарий #12)
> Не могу пройти мимо: разве наличие libX11 на сервере -- это такая большая
> проблема? 4 дополнительные библиотеки, суммарный размер которых -- 3.3 МБ.
На самом деле вопрос шире, и там 150 мегабайт
https://bugzilla.altlinux.org/show_bug.cgi?id=39204

И ещё есть такое негативное восклицание: Иксы на сервере?!

(In reply to Vitaly Lipatov from comment #14)
> (Ответ для Vladimir D. Seleznev на комментарий #12)
> > Не могу пройти мимо: разве наличие libX11 на сервере -- это такая большая
> > проблема? 4 дополнительные библиотеки, суммарный размер которых -- 3.3 МБ.
> На самом деле вопрос шире, и там 150 мегабайт
> https://bugzilla.altlinux.org/show_bug.cgi?id=39204

Вот это всё безобразие libX11 *не* вытягивает.

> И ещё есть такое негативное восклицание: Иксы на сервере?!

Возражу: это не иксы, а всего лишь libX11, библиотека. php, интерпретатор python 'а и компилятор на сервере куда опаснее.

На самом деле сборка с --without-x хотя и отключает линковку с libX11, но ничего не меняет, поскольку у libImageMagick есть зависимость на библиотеки, которые тянут
libgraphviz -> librsvg, libgtk+2 -> libpango, libcairo -> libX11, libEGL
libcairo -> libX11, libEGL

(Ответ для Vitaly Lipatov на комментарий #16)
> На самом деле сборка с --without-x хотя и отключает линковку с libX11, но
> ничего не меняет, поскольку у libImageMagick есть зависимость на библиотеки,
> которые тянут
> libgraphviz -> librsvg, libgtk+2 -> libpango, libcairo -> libX11, libEGL
> libcairo -> libX11, libEGL

Как выяснилось, в ImageMagick отдельно собираются модули (они их называют delegate)
https://lists.altlinux.org/pipermail/devel/2020-November/212346.html

Так вот, чтобы отделить зависимости на libgraphviz, libcairo и libX11, достаточно отдельно упаковать такие delegate
как
pango
svg
dot


К сожалению, сборка с --with-x приводит к тому, что libX11 линкуется со всеми делегатами.

Может быть, нам согласовать сборку подпакетов?
Например, в Fedora вынесен подпакет djvu.
Мы могли бы сделать подпакеты djvu, pango, svg, dot.

(In reply to Vitaly Lipatov from comment #17)

> Мы могли бы сделать подпакеты djvu, pango, svg, dot.

На самом деле хорошая идея.

Осталось теперь придумать, как сделать так, что бы при обновлении и установке libImageMagick по зависимостям не потерялся существующий функционал, но при этом была возможность установить минимальный набор плагинов.

Все возникающие идеи опять упираются в то, что придётся как-то объяснить apt'у по apt-get install 'libMagickCore-6.Q16.so.6()(64bit)' устанавливать один набор пакетов, а другой по 
apt-get install 'libMagickCore-6.Q16.so.6()(64bit)' libImageMagick6.6-plugins-small

Если сделать два пакета с одним provides и разным набором модулей (или зависимостей на них), то мы получим ровно такую же ситуацию, как и с наличием двух пакетов в репозитории с одинаковым набором библиотек.

может быть у Димы есть какие-то идеи ?

(In reply to Anton Farygin from comment #19)
> Осталось теперь придумать, как сделать так, что бы при обновлении и
> установке libImageMagick по зависимостям не потерялся существующий
> функционал, но при этом была возможность установить минимальный набор
> плагинов.
> 
> Все возникающие идеи опять упираются в то, что придётся как-то объяснить
> apt'у по apt-get install 'libMagickCore-6.Q16.so.6()(64bit)' устанавливать
> один набор пакетов, а другой по 
> apt-get install 'libMagickCore-6.Q16.so.6()(64bit)'
> libImageMagick6.6-plugins-small

Первое, что приходит в голову - это переместить саму библиотеку libMagickCore в одноимённый подпакет, плагины тоже запаковать в подпакеты, а нынешний подпакет libImageMagick превратить в пустой с зависимостями на новые подпакеты, чтобы при обновлении ни у кого ничего не потерялось.

при перемещении библиотеки из одного пакета в другой apt'у, говорят, тоже плохеет. Я попробую такую схему, спасибо.

Если пустой пакет со старым именем, где раньше была библиотека, все новые пакеты с библиотеками вытаскивает по зависимостям, обновление не сломается. Я всегда так делаю.

(In reply to Vitaly Lipatov from comment #17)
> Может быть, нам согласовать сборку подпакетов?
> Например, в Fedora вынесен подпакет djvu.
> Мы могли бы сделать подпакеты djvu, pango, svg, dot.

Оффтопик: надо бы подобную разбивку сделать и для graphviz, чтобы он не тащил за собой GTK+.

(Ответ для Sergey V Turchin на комментарий #22)
> Если пустой пакет со старым именем, где раньше была библиотека, все новые
> пакеты с библиотеками вытаскивает по зависимостям, обновление не сломается.
> Я всегда так делаю.

Если пакет с библиотеками будет тащить все подпакеты с плагинами (через пустой пакет-заглушку), то тогда мечта Виталика о том, что можно поставить частично плагины - не сработает.

Если же не сделать такую завимисимость, то будет проблема у тех, кто тянет библиотеку через автозависимости - плагины не установятся.
Т.е. - у библиотеки должны быть тем или иным способом зависимости на плагины, т.к. без них она работать не умеет.

(Ответ для Vladimir D. Seleznev на комментарий #23)
> (In reply to Vitaly Lipatov from comment #17)
> > Может быть, нам согласовать сборку подпакетов?
> > Например, в Fedora вынесен подпакет djvu.
> > Мы могли бы сделать подпакеты djvu, pango, svg, dot.
> 
> Оффтопик: надо бы подобную разбивку сделать и для graphviz, чтобы он не
> тащил за собой GTK+.
https://bugzilla.altlinux.org/show_bug.cgi?id=39236

(Ответ для Anton Farygin на комментарий #21)
> при перемещении библиотеки из одного пакета в другой apt'у, говорят, тоже
> плохеет. Я попробую такую схему, спасибо.

Есть ещё вариант, который я хочу попробовать — просто собрать отдельный ImageMagick для серверных целей. И линковать с ним всё недесктопное. Потому как все эти разбиения на подпакеты — только лишние заморочки, а изначально заявленной цели (не линковаться с X11) всё равно не решит.

Собранный отдельно ImageMagick для серверных целей будет предоставлять те же библиотеки, что и собранный сейчас.
и это приведёт к серьёзным проблемам в репозитории.

А чем не устроил GraphicsMagick ?

(Ответ для Anton Farygin на комментарий #24)
> Если пакет с библиотеками будет тащить все подпакеты с плагинами (через
> пустой пакет-заглушку), то тогда мечта Виталика о том, что можно поставить
> частично плагины - не сработает.
Это другой пакет. Не для Виталия. Это пакет для успешного обновления и выкинуть его можно будет тогда, когда из обновлений текущего собираемого пакета исчезнет p9. От этого пакета никто не должен зависеть и при новой установке он в систему попадать не должен.

Это понятно. Но как сделать так, что бы при apt-get install <библиотека> ставился полный набор плагинов ?

(Ответ для Anton Farygin на комментарий #29)
> Это понятно. Но как сделать так, что бы при apt-get install <библиотека>
> ставился полный набор плагинов ?
Либо оставить, как есть, либо apt-get install ImageMagick-maxi какой-нибудь.

libMagickCore-6.Q16.so.6()(64bit) часто вообще просто по зависимостям вытягивается, там нет никакого maxi.

(Ответ для Anton Farygin на комментарий #31)
> libMagickCore-6.Q16.so.6()(64bit) часто вообще просто по зависимостям
> вытягивается, там нет никакого maxi.
Я и на это тоже отвечал в предыдущем сообщении. Кроме как ручными зависимостями не решить.

В целом всё понятно, спасибо всем за обсуждение, я добавил себе в планы переработать этот пакет и обязательно это сделаю тем или иным способом.

(In reply to Anton Farygin from comment #29)
> Это понятно. Но как сделать так, что бы при apt-get install <библиотека>
> ставился полный набор плагинов ?

Протащить в apt и/или rpm поддержку опциональных зависимостей (suggests/recommends/etc), и позволить как минимум 3 настройки: интерактивно спрашивать у пользователя ставить или нет (и что именно ставить, а что - нет), всегда ставить опциональные зависимости автоматически, никогда не ставить опциональные зависимости автоматически.

Могло бы помочь, если бы такая фича была. Но её нет.

а в rpm такую фичу уже притащили ?

(In reply to Anton Farygin from comment #35)
> а в rpm такую фичу уже притащили ?

Зависит от дистрибутива.

См. пункт "Weak dependencies":

https://rpm.org/user_doc/dependencies.html

Кажется, в каких-то спеках Федоры я такие зависимости видел.
Вот быстро нагуглил пример:

https://src.fedoraproject.org/rpms/binwalk/blob/master/f/binwalk.spec

По ссылке:

# Optional, for graphs and visualizations
Suggests:       python3-pyqtgraph
# Optional, for --disasm functionality
Suggests:       capstone
# Optional, for automatic extraction/decompression of files and data
Recommends:     mtd-utils gzip bzip2 tar arj p7zip p7zip-plugins cabextract squashfs-tools lzop srecord
Suggests:       sleuthkit

(Ответ для Aleksei Nikiforov на комментарий #34)
> (In reply to Anton Farygin from comment #29)
> > Это понятно. Но как сделать так, что бы при apt-get install <библиотека>
> > ставился полный набор плагинов ?
> 
> Протащить в apt и/или rpm поддержку опциональных зависимостей
> (suggests/recommends/etc), и позволить как минимум 3 настройки: интерактивно
> спрашивать у пользователя ставить или нет (и что именно ставить, а что -
> нет), всегда ставить опциональные зависимости автоматически, никогда не
> ставить опциональные зависимости автоматически.
> 
> Могло бы помочь, если бы такая фича была. Но её нет.
Давайте про это отдельную багу?

(Ответ для Aleksei Nikiforov на комментарий #36)
> (In reply to Anton Farygin from comment #35)
> > а в rpm такую фичу уже притащили ?
> 
> Зависит от дистрибутива.
> 
> См. пункт "Weak dependencies":
> 
> https://rpm.org/user_doc/dependencies.html
> 
> Кажется, в каких-то спеках Федоры я такие зависимости видел.
> Вот быстро нагуглил пример:
https://bugzilla.altlinux.org/show_bug.cgi?id=39242

(Ответ для Anton Farygin на комментарий #27)
> Собранный отдельно ImageMagick для серверных целей будет предоставлять те же
> библиотеки, что и собранный сейчас.
Нет, он будет предоставлять другие библиотеки, даже названием они будут отличаться.

> и это приведёт к серьёзным проблемам в репозитории.
Поэтому проблем в репозитории не будет.

> А чем не устроил GraphicsMagick ?
У php7-gmagick другой интерфейс (как минимум название класса). gm convert вместо convert устроила, но
с GraphicsMagick точно такие же проблемы с модулями и зависимостями.

Пока что я увидел, что можно вообще без магии *Magick обойтись.