Package Details: imagemagick-full-doc 7.1.1.30-1

Git Clone URL: https://aur.archlinux.org/imagemagick-full.git (read-only, click to copy)
Package Base: imagemagick-full
Description: An image viewing/manipulation program (Q32 HDRI with all possible features) (manual and API docs)
Upstream URL: https://www.imagemagick.org/
Keywords: convert graphics image imagemagick photo
Licenses: LicenseRef-custom
Conflicts: imagemagick-doc
Provides: imagemagick-doc
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 17
Popularity: 0.000107
First Submitted: 2015-12-27 13:40 (UTC)
Last Updated: 2024-04-09 02:57 (UTC)

Latest Comments

1 2 3 4 5 Next › Last »

dbermond commented on 2023-12-10 01:23 (UTC)

@frankspace using symlinks for different libraries is not a good practice and should be avoided. This can lead to unpredictable results and crashes.

dbermond commented on 2023-12-10 01:23 (UTC)

@dreieck regarding libumem, it does not make any difference, as there is no stable libumem package, and probably there will not be, as upstream libumem is abandoned and very old. Also, libumem builds in linux only with some unsupported patches, and I cannot remember if they apply to the old tagged version (probably not, as patches are based on git master). Removing imagemagick from provides is technically correct, but that's not so simple in this case. This package must conflict with imagemagick, and being such, any package that depends on imagemagick will not be able to use this one if it would not provide imagemagick. As far as I understand, making it to install alongside with repository imagemagick is not trivially possible, as the configuration files in '/etc' will conflict, and I'm not aware of a supported upstream way to specify a different directory for these files. A good reasonable solution is to make it provide imagemagick and let the user build/rebuild target packages against it, although being technically incorrect since it does not provide the same Q16 libraries.

frankspace commented on 2023-12-07 14:41 (UTC)

@dreieck and @dbermond, this is probably a very stupid question, but regarding 32-bit/16-bit compatibility, is there any particular reason why the distinction would actually break anything if you just added some symlinks? For example, ln -s /usr/lib/libMagickCore-7.Q32HDRI.so ${pkgdir}/usr/lib/libMagickCore-7.Q16HDRI.so and so on? That's literally what the official libudev0-shim package does, after all. And maybe it would break; I genuinely don't know. (This has nothing to do with the libumem or magickcache stuff, just the bit depth stuff.) If shimming wouldn't break anything, that'd seem to solve that particular problem, wouldn't it?

dreieck commented on 2023-11-07 19:19 (UTC) (edited on 2023-11-07 19:20 (UTC) by dreieck)

There is no libumem and magickcache stable packages, so the only option is depending on libumem-git and magickcache-git.

The conclusion is wrong. libumem-git provides libumem, magickcache-git provides magickcache. So the -git packages wills suffice to satisfy the dependencies.

If there would be a magickcache stable package, it currently needs code that is only in the magickcache git master branch, and will not compile with the old magickcache release from 2022

That is a valid argument to use magickcache-git over magickcache.
Does the same hold true for libumem-git?

Being a -full package, it uses 32-bit depth by design and does not provide 16-bit depth, so you need to recompile anything that needs the 16-bit depth libraries

Then you must remove the imagemagick and libmagick provides entries, since it is not a drop-in replacement for Arch Linux' imagemagick: Other Arch Linux repo software will not work.

You then should adapt the package that it can be installed in parallel with the stock imagemagick.

E.g. rename it to "imagemagick-32bit-full" or something similar.

Regards and thanks for the package!

dbermond commented on 2023-11-07 16:26 (UTC)

@dreieck There is no libumem and magickcache stable packages, so the only option is depending on libumem-git and magickcache-git. If there would be a magickcache stable package, it currently needs code that is only in the magickcache git master branch, and will not compile with the old magickcache release from 2022 (the stable magickcache tagged pre-release from 2022 does not even build for me). Being a -full package, it uses 32-bit depth by design and does not provide 16-bit depth, so you need to recompile anything that needs the 16-bit depth libraries. imagemagick should not conflict with imagemagick-full-doc, as it does not make sense since they should co-exist. It looks like the repository imagemagick-doc was merged into repository imagemagick, and in this case it should be merged here too (or remove the documentation from the package) to avoid such file conflicts (will be done in the next update).

dreieck commented on 2023-11-07 11:31 (UTC)

Please add imagemagick to the conflicts array of imagemagick-full-doc:

error: failed to commit transaction (conflicting files)
imagemagick: /usr/share/doc/ImageMagick-7/LICENSE exists in filesystem (owned by imagemagick-full-doc)
imagemagick: /usr/share/doc/ImageMagick-7/NEWS.txt exists in filesystem (owned by imagemagick-full-doc)
[...]
imagemagick: /usr/share/doc/ImageMagick-7/www/webp.html exists in filesystem (owned by imagemagick-full-doc)
Errors occurred, no packages were upgraded.

Regards!

dreieck commented on 2023-11-07 11:29 (UTC) (edited on 2023-11-07 11:29 (UTC) by dreieck)

A current build of this package misses the

/usr/lib/libMagick*-7.Q16HDRI.so*

files.
It only provides the

/usr/lib/libMagick*-7.Q32HDRI.so*

files (32 variant, not 16 variant).

Thus it fails to provide the dependencies for most packages which depend on imagemagick or libmagick.

E.G.:

$ digikam:

digikam: error while loading shared libraries: libMagick++-7.Q16HDRI.so.5: cannot open shared object file: No such file or directory

Can you please either fix this, or adapt the package such that it neither provides nor conflicts imagemagick and libmagick put complements it?

Regards!

dreieck commented on 2023-11-07 11:21 (UTC)

Ahoj,

Does it really need the -git variants of libumem and magickcache as make dependencies?

It not specifically, then please change to the non-git variant, since the -git package should have the non-git package in it's provides entry, and this makes the user free to choose which variant to install.

Regards!

nariox commented on 2019-01-19 03:04 (UTC)

Could you add "-$pkgver" to the provides? Otherwise, packages that require a particular version of imagemagick complain (e.g. php-imagick)

dbermond commented on 2018-07-09 16:48 (UTC)

@tmow I cannot reproduce your issue. Package is building fine for me.

It seems that you're using clang to build. Maybe this is a clang specific issue? Please try to use gcc.