Bug 39033

Summary: Разбить библиотеку ImageMagick на подпакеты для уменьшения количества устанавливаемых пакетов на сервера
Product: Sisyphus Reporter: Vitaly Lipatov <lav>
Component: libImageMagick6.6Assignee: Anton Farygin <rider>
Status: ASSIGNED --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: darktemplaralt, evg, ldv, mike, rider, vseleznv, zerg
Version: unstable   
Hardware: x86_64   
OS: Linux   
Bug Depends on: 34185    
Bug Blocks: 39214    

Description Vitaly Lipatov 2020-10-04 16:43:37 MSK
Раз уж захотели отдельным багом. По мотивам https://bugzilla.altlinux.org/show_bug.cgi?id=34185#c4


Библиотеки ImageMagick могут использовать на (веб)сервере, например, расширением php7-imagick, при установке которого приезжает libX11.

Конечно, в Ubuntu я вообще не нашёл php7-imagick, но WordPress зачем-то рекомендует его ставить.

--without-x	don't use the X Window System.

By default, ImageMagick uses the X11 delegate libraries if they are available. When --without-x is specified, use of X11 is disabled. The display, animate, and import sub-commands are not included. The remaining sub-commands have reduced functionality such as no access to X11 fonts (consider using Postscript or TrueType fonts instead).

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

Оставлю здесь некоторые пакеты, которые собираются с 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
Comment 1 Vitaly Lipatov 2020-10-04 16:50:45 MSK
Удаление 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.
Comment 2 Anton Farygin 2020-11-03 16:00:42 MSK
к сожалению, невозможно технически сделать конфликтующие библиотеки, предоставляющие одинаковый интерфейс.
Comment 3 Vitaly Lipatov 2020-11-03 23:47:46 MSK
(Ответ для Anton Farygin на комментарий #2)
> к сожалению, невозможно технически сделать конфликтующие библиотеки,
> предоставляющие одинаковый интерфейс.
Не очень понял, в чём проблема. Просто собирается несколько вариантов библиотеки с разными параметрами и пакуется в разные пакеты. Конфликтующими будут не библиотеки, а пакеты с ними, и можно будет выбрать, какой устанавливать.
Comment 4 Anton Farygin 2020-11-04 08:07:46 MSK
Т.е. - клиентов тоже собирать несколько вариантов ?
Я подумаю над этой идеей.
Comment 5 Anton Farygin 2020-11-04 08:29:22 MSK
посмотрел внимательнее, пока не придумал способа собрать параллельно библиотеку так, что бы её имя было каким-то другим. 

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

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

Добавить флаг для сборки без иксов можно, как предложено в задании 260912, но большого смысла не видно - всех клиентов этой библиотеки придётся пересобирать для сборки в таком варианте.
Comment 6 Vitaly Lipatov 2020-11-04 13:32:14 MSK
(Ответ для Anton Farygin на комментарий #5)
> посмотрел внимательнее, пока не придумал способа собрать параллельно
> библиотеку так, что бы её имя было каким-то другим. 
> 
> В других дистрибутивах предполагаемой схемы упаковки тоже не реализовано и,
> как правило, все собирают с иксами. Думаю, что оптимально было бы уговорить
> на такой функционал апстрим.
Им недостаёт там самой малости: загрузки libX11 через dl. Я не смотрел код, может быть они уже и сделали.

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

> Добавить флаг для сборки без иксов можно, как предложено в задании 260912,
> но большого смысла не видно - всех клиентов этой библиотеки придётся
> пересобирать для сборки в таком варианте.
Я поясню, в чём заблуждение: ABI библиотеки не меняется от того, собрана она с -with-x или без.
Поэтому страдать о пересборке не нужно.
Comment 7 Anton Farygin 2020-11-05 08:07:17 MSK
Одновременное существование libImageMagick с разными опциями сборки в составе репозитория приведёт к непредсказуемому результату при попытке поставить пакет 'libMagickCore-6.Q16.so.6()(64bit)'.
Comment 8 Vitaly Lipatov 2020-11-06 16:10:35 MSK
(Ответ для Anton Farygin на комментарий #7)
> Одновременное существование libImageMagick с разными опциями сборки в
> составе репозитория приведёт к непредсказуемому результату при попытке
> поставить пакет 'libMagickCore-6.Q16.so.6()(64bit)'.
Это глупость, результат будет предсказуем: будет установлен пакет с такой библиотекой.
Если кому-то нужен более конкретный пакет, он может указать зависимость на пакет, а не на библиотеку.
Comment 9 Anton Farygin 2020-11-06 18:02:27 MSK
нет, к сожалению обсуждение в devel идёт по правильному пути и да, результат будет действительно не предсказуем.

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

и сравнение abi Дима правильно предлагает сделать.
Comment 10 Vitaly Lipatov 2020-11-06 18:20:39 MSK
(Ответ для Anton Farygin на комментарий #9)
> нет, к сожалению обсуждение в devel идёт по правильному пути и да, результат
> будет действительно не предсказуем.
Ну тебе остаётся выбор:
- забыть про эту багу
- убрать @everybody из ACL
- ждать пакета ImageMagick с другим названием
Comment 11 Anton Farygin 2020-11-06 19:30:49 MSK
Я пока что снял everybody с пакета, что бы не возникло лишних вопросов, хотя последнее твоё изменения меня в принципе устраивает и его можно выложить.
Comment 12 Vladimir D. Seleznev 2020-11-06 20:06:11 MSK
Не могу пройти мимо: разве наличие 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)
Comment 13 Vitaly Lipatov 2020-11-06 22:16:40 MSK
(Ответ для 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
Comment 14 Vitaly Lipatov 2020-11-07 02:30:30 MSK
(Ответ для Vladimir D. Seleznev на комментарий #12)
> Не могу пройти мимо: разве наличие libX11 на сервере -- это такая большая
> проблема? 4 дополнительные библиотеки, суммарный размер которых -- 3.3 МБ.
На самом деле вопрос шире, и там 150 мегабайт
https://bugzilla.altlinux.org/show_bug.cgi?id=39204

И ещё есть такое негативное восклицание: Иксы на сервере?!
Comment 15 Vladimir D. Seleznev 2020-11-07 02:54:50 MSK
(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 'а и компилятор на сервере куда опаснее.
Comment 16 Vitaly Lipatov 2020-11-07 20:44:51 MSK
На самом деле сборка с --without-x хотя и отключает линковку с libX11, но ничего не меняет, поскольку у libImageMagick есть зависимость на библиотеки, которые тянут
libgraphviz -> librsvg, libgtk+2 -> libpango, libcairo -> libX11, libEGL
libcairo -> libX11, libEGL
Comment 17 Vitaly Lipatov 2020-11-07 22:21:42 MSK
(Ответ для 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.
Comment 18 Vladimir D. Seleznev 2020-11-09 04:10:51 MSK
(In reply to Vitaly Lipatov from comment #17)

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

На самом деле хорошая идея.
Comment 19 Anton Farygin 2020-11-09 12:26:24 MSK
Осталось теперь придумать, как сделать так, что бы при обновлении и установке 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 и разным набором модулей (или зависимостей на них), то мы получим ровно такую же ситуацию, как и с наличием двух пакетов в репозитории с одинаковым набором библиотек.

может быть у Димы есть какие-то идеи ?
Comment 20 Dmitry V. Levin 2020-11-09 14:11:14 MSK
(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 превратить в пустой с зависимостями на новые подпакеты, чтобы при обновлении ни у кого ничего не потерялось.
Comment 21 Anton Farygin 2020-11-09 14:15:16 MSK
при перемещении библиотеки из одного пакета в другой apt'у, говорят, тоже плохеет. Я попробую такую схему, спасибо.
Comment 22 Sergey V Turchin 2020-11-09 14:23:43 MSK
Если пустой пакет со старым именем, где раньше была библиотека, все новые пакеты с библиотеками вытаскивает по зависимостям, обновление не сломается. Я всегда так делаю.
Comment 23 Vladimir D. Seleznev 2020-11-09 15:09:06 MSK
(In reply to Vitaly Lipatov from comment #17)
> Может быть, нам согласовать сборку подпакетов?
> Например, в Fedora вынесен подпакет djvu.
> Мы могли бы сделать подпакеты djvu, pango, svg, dot.

Оффтопик: надо бы подобную разбивку сделать и для graphviz, чтобы он не тащил за собой GTK+.
Comment 24 Anton Farygin 2020-11-09 18:27:41 MSK
(Ответ для Sergey V Turchin на комментарий #22)
> Если пустой пакет со старым именем, где раньше была библиотека, все новые
> пакеты с библиотеками вытаскивает по зависимостям, обновление не сломается.
> Я всегда так делаю.

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

Если же не сделать такую завимисимость, то будет проблема у тех, кто тянет библиотеку через автозависимости - плагины не установятся.
Т.е. - у библиотеки должны быть тем или иным способом зависимости на плагины, т.к. без них она работать не умеет.
Comment 25 Vitaly Lipatov 2020-11-09 20:06:42 MSK
(Ответ для 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
Comment 26 Vitaly Lipatov 2020-11-09 20:09:39 MSK
(Ответ для Anton Farygin на комментарий #21)
> при перемещении библиотеки из одного пакета в другой apt'у, говорят, тоже
> плохеет. Я попробую такую схему, спасибо.

Есть ещё вариант, который я хочу попробовать — просто собрать отдельный ImageMagick для серверных целей. И линковать с ним всё недесктопное. Потому как все эти разбиения на подпакеты — только лишние заморочки, а изначально заявленной цели (не линковаться с X11) всё равно не решит.
Comment 27 Anton Farygin 2020-11-10 09:32:22 MSK
Собранный отдельно ImageMagick для серверных целей будет предоставлять те же библиотеки, что и собранный сейчас.
и это приведёт к серьёзным проблемам в репозитории.

А чем не устроил GraphicsMagick ?
Comment 28 Sergey V Turchin 2020-11-10 10:28:54 MSK
(Ответ для Anton Farygin на комментарий #24)
> Если пакет с библиотеками будет тащить все подпакеты с плагинами (через
> пустой пакет-заглушку), то тогда мечта Виталика о том, что можно поставить
> частично плагины - не сработает.
Это другой пакет. Не для Виталия. Это пакет для успешного обновления и выкинуть его можно будет тогда, когда из обновлений текущего собираемого пакета исчезнет p9. От этого пакета никто не должен зависеть и при новой установке он в систему попадать не должен.
Comment 29 Anton Farygin 2020-11-10 10:46:56 MSK
Это понятно. Но как сделать так, что бы при apt-get install <библиотека> ставился полный набор плагинов ?
Comment 30 Sergey V Turchin 2020-11-10 10:55:30 MSK
(Ответ для Anton Farygin на комментарий #29)
> Это понятно. Но как сделать так, что бы при apt-get install <библиотека>
> ставился полный набор плагинов ?
Либо оставить, как есть, либо apt-get install ImageMagick-maxi какой-нибудь.
Comment 31 Anton Farygin 2020-11-10 10:57:10 MSK
libMagickCore-6.Q16.so.6()(64bit) часто вообще просто по зависимостям вытягивается, там нет никакого maxi.
Comment 32 Sergey V Turchin 2020-11-10 11:03:14 MSK
(Ответ для Anton Farygin на комментарий #31)
> libMagickCore-6.Q16.so.6()(64bit) часто вообще просто по зависимостям
> вытягивается, там нет никакого maxi.
Я и на это тоже отвечал в предыдущем сообщении. Кроме как ручными зависимостями не решить.
Comment 33 Anton Farygin 2020-11-10 11:05:05 MSK
В целом всё понятно, спасибо всем за обсуждение, я добавил себе в планы переработать этот пакет и обязательно это сделаю тем или иным способом.
Comment 34 Aleksei Nikiforov 2020-11-10 11:05:22 MSK
(In reply to Anton Farygin from comment #29)
> Это понятно. Но как сделать так, что бы при apt-get install <библиотека>
> ставился полный набор плагинов ?

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

Могло бы помочь, если бы такая фича была. Но её нет.
Comment 35 Anton Farygin 2020-11-10 11:06:38 MSK
а в rpm такую фичу уже притащили ?
Comment 36 Aleksei Nikiforov 2020-11-10 11:41:43 MSK
(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
Comment 37 Vitaly Lipatov 2020-11-10 12:54:14 MSK
(Ответ для Aleksei Nikiforov на комментарий #34)
> (In reply to Anton Farygin from comment #29)
> > Это понятно. Но как сделать так, что бы при apt-get install <библиотека>
> > ставился полный набор плагинов ?
> 
> Протащить в apt и/или rpm поддержку опциональных зависимостей
> (suggests/recommends/etc), и позволить как минимум 3 настройки: интерактивно
> спрашивать у пользователя ставить или нет (и что именно ставить, а что -
> нет), всегда ставить опциональные зависимости автоматически, никогда не
> ставить опциональные зависимости автоматически.
> 
> Могло бы помочь, если бы такая фича была. Но её нет.
Давайте про это отдельную багу?
Comment 38 Vitaly Lipatov 2020-11-10 16:09:21 MSK
(Ответ для 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
Comment 39 Vitaly Lipatov 2020-11-10 16:22:54 MSK
(Ответ для Anton Farygin на комментарий #27)
> Собранный отдельно ImageMagick для серверных целей будет предоставлять те же
> библиотеки, что и собранный сейчас.
Нет, он будет предоставлять другие библиотеки, даже названием они будут отличаться.

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

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

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