This is tracker bug for packages that depend only on imagemagick and not on (imagemagick or graphicsmagick).
It might be advisable to have a stable version of graphicsmagick on many archs before deploying this on a global scale.
*** Bug 306807 has been marked as a duplicate of this bug. ***
I just found out that you are trying to deploy this. As QA member i would highly recommend you to use virtual/imagemagick instead of poluting so much packages with || deps Also what you should do: Get same keywords on both packages. Pick one that is preffered and put it into || depgraph first :] (My humble opinion i sthat graphicmagic should win but your decision :P)
Isn't it better to introduce virtual/imagemagick depending on || (media-gfx/imagemagick media-gfx/graphicsmagick[imagemagick]) and depend on it?
Something else- does anyone know how the imagemagick useflags map on graphicsmagic?
As far as I know, only graphicsmagick execs (montage, convert,...) are compatible with imagemagick, but not the library. So did you actually check this, and if this is true, do all those packages do not need the imagemagick library?
(In reply to comment #6) > As far as I know, only graphicsmagick execs (montage, convert,...) are > compatible with imagemagick, but not the library. > From http://www.graphicsmagick.org/FAQ.html#how-does-graphicsmagick-differ-from-imagemagick (official graphicsmagick FAQ): > Other than utilities being executed as sub-commands of the 'gm' command, the > command-line syntax and programming APIs remain entirely upward compatible > with ImageMagick 5.5.2. > So did you actually check this, and if this is true, do all those packages do > not need the imagemagick library? > No, I didn't test (that's >100 pkgs, I don't have time and resources). Bus AFAIK they SHOULD (as per RFC2119) need either library. There are false positives (the first one detected is #314249) that for sure need imagemagick, but not all of them.
I'm very tempted to mass-close the bugs as LATER. Why? Because we need a virtual: - let's not add just a bunch of || () deps on all the packages, try to simplify the depgraph; - USE flags such as cxx, svg, png, jpeg, … need to be passed through, let's not make the whole depgraph an absurd mess. Also, does graphicsmagick[imagemagick] install -config files to change the linking libraries and link the libraries as well? At least for rmagick that could be the case. But again, this cannot be done with such a mass-filing of bugs without being properly planned.
(In reply to comment #8) If the proper way to solve the problem is creating a virtual, I agree. What should be done before? Who should be responsible for that? Which flags should be passed? Does graphicsmagick need to be stabilized before? rmagick is excluded wrt http://bugs.gentoo.org/show_bug.cgi?id=306807#c3. I don't know about internals of graphicsmagic, just rely on abovementioned faq.
(In reply to comment #9) > (In reply to comment #8) > If the proper way to solve the problem is creating a virtual, I agree. > > What should be done before? Discuss it on gentoo-dev mailing list. > Who should be responsible for that? Maintainer of the virtual will be the graphics team. > Which flags should be passed? I don't understand the question. > Does graphicsmagick need to be stabilized before? No. One of the virtual providers must be stable, which is true for imagemagick. > rmagick is excluded wrt http://bugs.gentoo.org/show_bug.cgi?id=306807#c3. I > don't know about internals of graphicsmagic, just rely on abovementioned faq. That is no problem, it can then depend on imagemagick solely.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > Which flags should be passed? > > I don't understand the question. I am asking about USE flags, the flags mentioned in comment #8. I am no imagemagic/graphicsmagic developer, so I don't know what is needed and what isn't.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #8) > > > Which flags should be passed? > > > > I don't understand the question. > > I am asking about USE flags, the flags mentioned in comment #8. I am no > imagemagic/graphicsmagic developer, so I don't know what is needed and what > isn't. Ok, Diego is talking about Package A requests media-gfx/imagemagick built with USE=svg, so the virtual needs a USE=svg, too, which is called from A like this "virtual/imagemagick[svg]", which in turn requests svg? ( || ( media-gfx/imagemagick[svg] media-gfx/graphicmagick[svg] ) ) This is doable with a lot of precautious work (testing with both alternatives installed). Both programs have a lot of USE flags, so this could be a lot of work. I should add that I am available for commits, though my time for testing is limited.
Created attachment 227651 [details] question/proposal (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #9) > > > > (In reply to comment #8) > > > > Which flags should be passed? > > > > > > I don't understand the question. > > > > I am asking about USE flags, the flags mentioned in comment #8. I am no > > imagemagic/graphicsmagic developer, so I don't know what is needed and what > > isn't. > > > Ok, Diego is talking about > > Package A requests media-gfx/imagemagick built with USE=svg, so the virtual > needs a USE=svg, too, which is called from A like this > "virtual/imagemagick[svg]", which in turn requests > svg? ( || ( media-gfx/imagemagick[svg] media-gfx/graphicmagick[svg] ) ) > > This is doable with a lot of precautious work (testing with both alternatives > installed). Both programs have a lot of USE flags, so this could be a lot of > work. I should add that I am available for commits, though my time for testing > is limited. > you mean something like that? (not tested)
(In reply to comment #7) > From > http://www.graphicsmagick.org/FAQ.html#how-does-graphicsmagick-differ-from-imagemagick > (official graphicsmagick FAQ): > > > Other than utilities being executed as sub-commands of the 'gm' command, the > > command-line syntax and programming APIs remain entirely upward compatible > > with ImageMagick 5.5.2. Which does not mean they are compatible now. imagemagick uses I do not have the time to test those 100 packages either. Many packages use the ImageMagick.pc or the Magick-config utility to check for the existence of imagemagick. The corresponding ones in graphicsmagick are GraphicsMagick.pc and GraphicsMagick-config, and so are the library names. If the APIs are truely compatible, we would need to make links to the magick packages to a common library name, make a virtual and probably an eselect moduels for it, and change all ebuilds depending on this bug (hopefully with upstream support). If the library APIs are not compatible but only the execs, then you want to check every package to see if they are dependent only on them and not on the library. I've seen some packages just needing the 'convert' utility. Then make a virtual and a blocker. Both cases mean quite a lot of tedious work ahead. \me runs.
(In reply to comment #13) > you mean something like that? (not tested) Along that lines, yes. But it is still needed to test every single package out there, before adjusting the DEPEND lines. This is not against the work you already put in, but we are maybe talking about little benefit with a lot of costs.
(In reply to comment #8) > I'm very tempted to mass-close the bugs as LATER. Why? Because we need a > virtual: > > - let's not add just a bunch of || () deps on all the packages, try to > simplify the depgraph; > - USE flags such as cxx, svg, png, jpeg, … need to be passed through, let's > not make the whole depgraph an absurd mess. > > Also, does graphicsmagick[imagemagick] install -config files to change the > linking libraries and link the libraries as well? At least for rmagick that > could be the case. > > But again, this cannot be done with such a mass-filing of bugs without being > properly planned. > ^^ People should really read this and TEST the pkgs before blindly changing any deps. Packages might hardcore linking like e.g. LIBS="-lMagickCore" and no such thing gets installed by graphicsmagick[imagemagick]. Then again if it's only the commands it's using, it's most likely compatible. At any rate: TEST before "fixing" any of these bugs
I've got here from the linked bug 314257. Has any progress been made here? If not, I'm tempted to close the kopete bug until someone reaches a decision about this issue.
Is there anything I can do here as a user? If you install e.g. octave on your system, which has a hard dependency on graphicsmagick, you'll receive many blockers and problems. If virtual or not, I think this bug should be fixed (brute force approach first, maybe better solution later) to transfer the tree into a more consistent state.
AS mentioned in my previous comments above, the proper resolution right now is: 1. Check whether the package hard depends on one of the libMagick* shared libraries. 2. If yes, leave the dependency to imagemagick only. You are done. 3. Check if the package only depends on one of the common utilities to imagemagick and graphicsmagick[imagemagick]: convert, montage, animate, composite, conjure, compare, display, identify, import, mogrify 4. add the || (media-gfx/imagemagick media-gfx/graphicsmagick[imagemagick]) to the dependencies of the package. You are done. 5. If your package depends on libGraphicsMagick* then hard depend on media-libs/graphicsmagick. You are done. For octave users, you can just add "media-gfx/graphicsmagick -imagemagick" to your package.use to avoid conflicts.
By the mass of depended bugs, why do not add we a virtual package eg virtual/imagamagick for the imagemagick vs. graphicsmagick crap ?
As most reverse deps will need subslots usage, this should probably be handled like ffmpeg vs. libav, I mean, with USE flags, should this be discussed in mailing list too or...?
@soap, weren't you handling that?
(In reply to Michał Górny from comment #22) > @soap, weren't you handling that? Yes, it's on my to do list, I'll work on it soon.
@QA team, any updates on this? Each time I need to rely on @preserved-rebuild on imagemagick updates I wonder about what path to follow :/ In: https://archives.gentoo.org/gentoo-dev/message/7b713b722e2c4f8837217247bd2ebb96 I show that my preference would be to handle it like ffmpeg vs libav to allow the usage of subslots (that are needed in this case)... but, for now, I haven't started to update the packages when I hit the rebuilds because I don't know if people agree on that solution :|
(In reply to Pacho Ramos from comment #24) > @QA team, any updates on this? Each time I need to rely on > @preserved-rebuild on imagemagick updates I wonder about what path to follow > :/ > > In: > https://archives.gentoo.org/gentoo-dev/message/ > 7b713b722e2c4f8837217247bd2ebb96 > > I show that my preference would be to handle it like ffmpeg vs libav to > allow the usage of subslots (that are needed in this case)... but, for now, > I haven't started to update the packages when I hit the rebuilds because I > don't know if people agree on that solution :| Hey Pacho, yes it's still on my to do list ;) Give me some time, I'll try to do it on the weekend. Toralf gave me a list of all rdeps that link to im/gm.
Nice, thanks :)
(In reply to Pacho Ramos from comment #26) > Nice, thanks :) Please double-check: https://github.com/gentoo/gentoo/pull/3907
Finally merged. For linking rev deps, we force consuming packages to use the ffmpeg/libressl-style USE discriminating construct. Please open a new bug tracker for all packages that have missing := on imagemagick and/or graphicsmagick. I guess the virtual problem is solved now. commit e53d7fd2ceed3894953eccecfefe4ef0af2fe0df Author: David Seifert <soap@gentoo.org> Date: Sat Feb 11 20:21:49 2017 +0100 virtual/imagemagick-tools: Add virtual for media-gfx/{image,graphics}magick * Packages that do **not** link to either library and just consume the runtime command-line tools of either package should depend on the virtual in general. This reduces the complexity of the depgraph and makes central USE flag handling much easier. * Packages that can link to either imagemagick or graphicsmagick need more delicate handling in order to be usable with subslots. 1) Packages that **require** either imagemagick or graphicsmagick should use USE="graphicsmagick" to differentiate which one to use by specifying !graphicsmagick? ( media-gfx/imagemagick:= ) graphicsmagick? ( media-gfx/graphicsmagick:= ) 2) Packages that **may** use either imagemagick or graphicsmagick, but don't **require** it, should additionally add USE="imagemagick" and specify imagemagick? ( !graphicsmagick? ( media-gfx/imagemagick:= ) graphicsmagick? ( media-gfx/graphicsmagick:= ) ) So that the semantics become: USE="imagemagick" = "I want to build with optional imagemagick or graphicsmagick support" USE="-imagemagick" = "I do NOT want optional support for imagemagick and/or graphicsmagick" USE="-graphicsmagick" = "I want to build against media-gfx/imagemagick" USE="graphicsmagick" = "I want to build against media-gfx/graphicsmagick" This avoids package.use pollution due to setting REQUIRED_USE. Bug: https://bugs.gentoo.org/show_bug.cgi?id=314431
