Раз уж захотели отдельным багом. По мотивам 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
Удаление 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 обойтись.
