39033 2020-10-04 16:43:37 +0300 Разбить библиотеку ImageMagick на подпакеты для уменьшения количества устанавливаемых пакетов на сервера 2023-06-21 18:15:46 +0300 1 1 4 Development Sisyphus libImageMagick6.6 unstable x86_64 Linux ASSIGNED P5 normal --- 34185 39214 1 lav rider darktemplaralt evg ldv mike rider vseleznv zerg qa-sisyphus oldest_to_newest 192994 0 lav 2020-10-04 16:43:37 +0300 Раз уж захотели отдельным багом. По мотивам 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 192995 1 lav 2020-10-04 16:50:45 +0300 Удаление 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. 193743 2 rider 2020-11-03 16:00:42 +0300 к сожалению, невозможно технически сделать конфликтующие библиотеки, предоставляющие одинаковый интерфейс. 193755 3 lav 2020-11-03 23:47:46 +0300 (Ответ для Anton Farygin на комментарий #2) > к сожалению, невозможно технически сделать конфликтующие библиотеки, > предоставляющие одинаковый интерфейс. Не очень понял, в чём проблема. Просто собирается несколько вариантов библиотеки с разными параметрами и пакуется в разные пакеты. Конфликтующими будут не библиотеки, а пакеты с ними, и можно будет выбрать, какой устанавливать. 193758 4 rider 2020-11-04 08:07:46 +0300 Т.е. - клиентов тоже собирать несколько вариантов ? Я подумаю над этой идеей. 193759 5 rider 2020-11-04 08:29:22 +0300 посмотрел внимательнее, пока не придумал способа собрать параллельно библиотеку так, что бы её имя было каким-то другим. В других дистрибутивах предполагаемой схемы упаковки тоже не реализовано и, как правило, все собирают с иксами. Думаю, что оптимально было бы уговорить на такой функционал апстрим. Задача просматривается такая - возможность одновременной работы и установки в системе библиотек ImageMagick, слинкованных с X11 и без. Добавить флаг для сборки без иксов можно, как предложено в задании 260912, но большого смысла не видно - всех клиентов этой библиотеки придётся пересобирать для сборки в таком варианте. 193764 6 lav 2020-11-04 13:32:14 +0300 (Ответ для Anton Farygin на комментарий #5) > посмотрел внимательнее, пока не придумал способа собрать параллельно > библиотеку так, что бы её имя было каким-то другим. > > В других дистрибутивах предполагаемой схемы упаковки тоже не реализовано и, > как правило, все собирают с иксами. Думаю, что оптимально было бы уговорить > на такой функционал апстрим. Им недостаёт там самой малости: загрузки libX11 через dl. Я не смотрел код, может быть они уже и сделали. > Задача просматривается такая - возможность одновременной работы и установки > в системе библиотек ImageMagick, слинкованных с X11 и без. Нужна возможность одновременной сборки, а потом установки одного из вариантов. > Добавить флаг для сборки без иксов можно, как предложено в задании 260912, > но большого смысла не видно - всех клиентов этой библиотеки придётся > пересобирать для сборки в таком варианте. Я поясню, в чём заблуждение: ABI библиотеки не меняется от того, собрана она с -with-x или без. Поэтому страдать о пересборке не нужно. 193779 7 rider 2020-11-05 08:07:17 +0300 Одновременное существование libImageMagick с разными опциями сборки в составе репозитория приведёт к непредсказуемому результату при попытке поставить пакет 'libMagickCore-6.Q16.so.6()(64bit)'. 193836 8 lav 2020-11-06 16:10:35 +0300 (Ответ для Anton Farygin на комментарий #7) > Одновременное существование libImageMagick с разными опциями сборки в > составе репозитория приведёт к непредсказуемому результату при попытке > поставить пакет 'libMagickCore-6.Q16.so.6()(64bit)'. Это глупость, результат будет предсказуем: будет установлен пакет с такой библиотекой. Если кому-то нужен более конкретный пакет, он может указать зависимость на пакет, а не на библиотеку. 193838 9 rider 2020-11-06 18:02:27 +0300 нет, к сожалению обсуждение в devel идёт по правильному пути и да, результат будет действительно не предсказуем. Если бы у таких пакетов, провайдящих разные библиотеки, можно было задавать веса для автоматического выбора, то можно было бы попробовать. и сравнение abi Дима правильно предлагает сделать. 193839 10 lav 2020-11-06 18:20:39 +0300 (Ответ для Anton Farygin на комментарий #9) > нет, к сожалению обсуждение в devel идёт по правильному пути и да, результат > будет действительно не предсказуем. Ну тебе остаётся выбор: - забыть про эту багу - убрать @everybody из ACL - ждать пакета ImageMagick с другим названием 193841 11 rider 2020-11-06 19:30:49 +0300 Я пока что снял everybody с пакета, что бы не возникло лишних вопросов, хотя последнее твоё изменения меня в принципе устраивает и его можно выложить. 193843 12 vseleznv 2020-11-06 20:06:11 +0300 Не могу пройти мимо: разве наличие 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) 193845 13 lav 2020-11-06 22:16:40 +0300 (Ответ для 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 193850 14 lav 2020-11-07 02:30:30 +0300 (Ответ для Vladimir D. Seleznev на комментарий #12) > Не могу пройти мимо: разве наличие libX11 на сервере -- это такая большая > проблема? 4 дополнительные библиотеки, суммарный размер которых -- 3.3 МБ. На самом деле вопрос шире, и там 150 мегабайт https://bugzilla.altlinux.org/show_bug.cgi?id=39204 И ещё есть такое негативное восклицание: Иксы на сервере?! 193852 15 vseleznv 2020-11-07 02:54:50 +0300 (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 'а и компилятор на сервере куда опаснее. 193880 16 lav 2020-11-07 20:44:51 +0300 На самом деле сборка с --without-x хотя и отключает линковку с libX11, но ничего не меняет, поскольку у libImageMagick есть зависимость на библиотеки, которые тянут libgraphviz -> librsvg, libgtk+2 -> libpango, libcairo -> libX11, libEGL libcairo -> libX11, libEGL 193886 17 lav 2020-11-07 22:21:42 +0300 (Ответ для 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. 193933 18 vseleznv 2020-11-09 04:10:51 +0300 (In reply to Vitaly Lipatov from comment #17) > Мы могли бы сделать подпакеты djvu, pango, svg, dot. На самом деле хорошая идея. 193954 19 rider 2020-11-09 12:26:24 +0300 Осталось теперь придумать, как сделать так, что бы при обновлении и установке 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 и разным набором модулей (или зависимостей на них), то мы получим ровно такую же ситуацию, как и с наличием двух пакетов в репозитории с одинаковым набором библиотек. может быть у Димы есть какие-то идеи ? 193960 20 ldv 2020-11-09 14:11:14 +0300 (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 превратить в пустой с зависимостями на новые подпакеты, чтобы при обновлении ни у кого ничего не потерялось. 193962 21 rider 2020-11-09 14:15:16 +0300 при перемещении библиотеки из одного пакета в другой apt'у, говорят, тоже плохеет. Я попробую такую схему, спасибо. 193964 22 zerg 2020-11-09 14:23:43 +0300 Если пустой пакет со старым именем, где раньше была библиотека, все новые пакеты с библиотеками вытаскивает по зависимостям, обновление не сломается. Я всегда так делаю. 193967 23 vseleznv 2020-11-09 15:09:06 +0300 (In reply to Vitaly Lipatov from comment #17) > Может быть, нам согласовать сборку подпакетов? > Например, в Fedora вынесен подпакет djvu. > Мы могли бы сделать подпакеты djvu, pango, svg, dot. Оффтопик: надо бы подобную разбивку сделать и для graphviz, чтобы он не тащил за собой GTK+. 193971 24 rider 2020-11-09 18:27:41 +0300 (Ответ для Sergey V Turchin на комментарий #22) > Если пустой пакет со старым именем, где раньше была библиотека, все новые > пакеты с библиотеками вытаскивает по зависимостям, обновление не сломается. > Я всегда так делаю. Если пакет с библиотеками будет тащить все подпакеты с плагинами (через пустой пакет-заглушку), то тогда мечта Виталика о том, что можно поставить частично плагины - не сработает. Если же не сделать такую завимисимость, то будет проблема у тех, кто тянет библиотеку через автозависимости - плагины не установятся. Т.е. - у библиотеки должны быть тем или иным способом зависимости на плагины, т.к. без них она работать не умеет. 193980 25 lav 2020-11-09 20:06:42 +0300 (Ответ для 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 193981 26 lav 2020-11-09 20:09:39 +0300 (Ответ для Anton Farygin на комментарий #21) > при перемещении библиотеки из одного пакета в другой apt'у, говорят, тоже > плохеет. Я попробую такую схему, спасибо. Есть ещё вариант, который я хочу попробовать — просто собрать отдельный ImageMagick для серверных целей. И линковать с ним всё недесктопное. Потому как все эти разбиения на подпакеты — только лишние заморочки, а изначально заявленной цели (не линковаться с X11) всё равно не решит. 194007 27 rider 2020-11-10 09:32:22 +0300 Собранный отдельно ImageMagick для серверных целей будет предоставлять те же библиотеки, что и собранный сейчас. и это приведёт к серьёзным проблемам в репозитории. А чем не устроил GraphicsMagick ? 194009 28 zerg 2020-11-10 10:28:54 +0300 (Ответ для Anton Farygin на комментарий #24) > Если пакет с библиотеками будет тащить все подпакеты с плагинами (через > пустой пакет-заглушку), то тогда мечта Виталика о том, что можно поставить > частично плагины - не сработает. Это другой пакет. Не для Виталия. Это пакет для успешного обновления и выкинуть его можно будет тогда, когда из обновлений текущего собираемого пакета исчезнет p9. От этого пакета никто не должен зависеть и при новой установке он в систему попадать не должен. 194011 29 rider 2020-11-10 10:46:56 +0300 Это понятно. Но как сделать так, что бы при apt-get install <библиотека> ставился полный набор плагинов ? 194013 30 zerg 2020-11-10 10:55:30 +0300 (Ответ для Anton Farygin на комментарий #29) > Это понятно. Но как сделать так, что бы при apt-get install <библиотека> > ставился полный набор плагинов ? Либо оставить, как есть, либо apt-get install ImageMagick-maxi какой-нибудь. 194015 31 rider 2020-11-10 10:57:10 +0300 libMagickCore-6.Q16.so.6()(64bit) часто вообще просто по зависимостям вытягивается, там нет никакого maxi. 194016 32 zerg 2020-11-10 11:03:14 +0300 (Ответ для Anton Farygin на комментарий #31) > libMagickCore-6.Q16.so.6()(64bit) часто вообще просто по зависимостям > вытягивается, там нет никакого maxi. Я и на это тоже отвечал в предыдущем сообщении. Кроме как ручными зависимостями не решить. 194017 33 rider 2020-11-10 11:05:05 +0300 В целом всё понятно, спасибо всем за обсуждение, я добавил себе в планы переработать этот пакет и обязательно это сделаю тем или иным способом. 194018 34 darktemplaralt 2020-11-10 11:05:22 +0300 (In reply to Anton Farygin from comment #29) > Это понятно. Но как сделать так, что бы при apt-get install <библиотека> > ставился полный набор плагинов ? Протащить в apt и/или rpm поддержку опциональных зависимостей (suggests/recommends/etc), и позволить как минимум 3 настройки: интерактивно спрашивать у пользователя ставить или нет (и что именно ставить, а что - нет), всегда ставить опциональные зависимости автоматически, никогда не ставить опциональные зависимости автоматически. Могло бы помочь, если бы такая фича была. Но её нет. 194019 35 rider 2020-11-10 11:06:38 +0300 а в rpm такую фичу уже притащили ? 194021 36 darktemplaralt 2020-11-10 11:41:43 +0300 (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 194027 37 lav 2020-11-10 12:54:14 +0300 (Ответ для Aleksei Nikiforov на комментарий #34) > (In reply to Anton Farygin from comment #29) > > Это понятно. Но как сделать так, что бы при apt-get install <библиотека> > > ставился полный набор плагинов ? > > Протащить в apt и/или rpm поддержку опциональных зависимостей > (suggests/recommends/etc), и позволить как минимум 3 настройки: интерактивно > спрашивать у пользователя ставить или нет (и что именно ставить, а что - > нет), всегда ставить опциональные зависимости автоматически, никогда не > ставить опциональные зависимости автоматически. > > Могло бы помочь, если бы такая фича была. Но её нет. Давайте про это отдельную багу? 194042 38 lav 2020-11-10 16:09:21 +0300 (Ответ для 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 194045 39 lav 2020-11-10 16:22:54 +0300 (Ответ для Anton Farygin на комментарий #27) > Собранный отдельно ImageMagick для серверных целей будет предоставлять те же > библиотеки, что и собранный сейчас. Нет, он будет предоставлять другие библиотеки, даже названием они будут отличаться. > и это приведёт к серьёзным проблемам в репозитории. Поэтому проблем в репозитории не будет. > А чем не устроил GraphicsMagick ? У php7-gmagick другой интерфейс (как минимум название класса). gm convert вместо convert устроила, но с GraphicsMagick точно такие же проблемы с модулями и зависимостями. Пока что я увидел, что можно вообще без магии *Magick обойтись.