Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 314431 - [TRACKER] packages should depend on || (media-gfx/imagemagick media-gfx/graphicsmagick[imagemagick])
Summary: [TRACKER] packages should depend on || (media-gfx/imagemagick media-gfx/graph...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Andreas K. Hüttel
URL: https://archives.gentoo.org/gentoo-de...
Whiteboard:
Keywords: Tracker
: 306807 (view as bug list)
Depends on: 314227 314281 314343 314397 309055 314203 314205 314207 314209 314211 314213 314215 314217 314219 314221 314223 314225 314231 314233 314235 314237 314239 314241 314243 314245 314249 314251 314253 314255 314257 314259 314261 314263 314265 314267 314269 314271 314273 314275 314277 314279 314283 314285 314287 314289 314291 314293 314295 314297 314299 314301 314303 314305 314307 314309 314311 314313 314315 314317 314319 314321 314323 314325 314327 314329 314331 314333 314335 314337 314339 314341 314345 314347 314349 314351 314353 314355 314357 314359 314361 314363 314365 314367 314369 314371 314373 314375 314377 314379 314381 314383 314385 314387 314389 314391 314393 314395 314399 314401 314403 314405 314407 314409 314411 314413 314415 314417 314419 314421 314423 314425 314427 365385 586284
Blocks:
  Show dependency tree
 
Reported: 2010-04-09 22:35 UTC by Wojciech Porczyk
Modified: 2020-07-30 02:39 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
question/proposal (imagemagick-0.ebuild,939 bytes, text/plain)
2010-04-13 19:59 UTC, Wojciech Porczyk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wojciech Porczyk 2010-04-09 22:35:30 UTC
This is tracker bug for packages that depend only on imagemagick and not on (imagemagick or graphicsmagick).
Comment 1 Thomas Kahle (RETIRED) gentoo-dev 2010-04-10 02:10:12 UTC
It might be advisable to have a stable version of graphicsmagick on many archs before deploying this on a global scale.
Comment 2 Andreas K. Hüttel gentoo-dev 2010-04-10 09:04:10 UTC
*** Bug 306807 has been marked as a duplicate of this bug. ***
Comment 3 Tomáš Chvátal (RETIRED) gentoo-dev 2010-04-10 09:41:52 UTC
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)
Comment 4 Andrey Grozin gentoo-dev 2010-04-11 11:41:25 UTC
Isn't it better to introduce virtual/imagemagick depending on || (media-gfx/imagemagick media-gfx/graphicsmagick[imagemagick]) and depend on it?
Comment 5 Andreas K. Hüttel gentoo-dev 2010-04-11 16:52:01 UTC
Something else- does anyone know how the imagemagick useflags map on graphicsmagic?
Comment 6 Sébastien Fabbro (RETIRED) gentoo-dev 2010-04-12 17:30:48 UTC
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?

Comment 7 Wojciech Porczyk 2010-04-12 23:27:10 UTC
(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.
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-04-13 13:00:39 UTC
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.
Comment 9 Wojciech Porczyk 2010-04-13 18:05:53 UTC
(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.
Comment 10 Christian Faulhammer (RETIRED) gentoo-dev 2010-04-13 18:10:06 UTC
(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.
Comment 11 Wojciech Porczyk 2010-04-13 19:13:35 UTC
(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.
Comment 12 Christian Faulhammer (RETIRED) gentoo-dev 2010-04-13 19:31:17 UTC
(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.
Comment 13 Wojciech Porczyk 2010-04-13 19:59:36 UTC
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)
Comment 14 Sébastien Fabbro (RETIRED) gentoo-dev 2010-04-13 20:20:41 UTC
(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.
Comment 15 Christian Faulhammer (RETIRED) gentoo-dev 2010-04-13 20:35:05 UTC
(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. 

Comment 16 Samuli Suominen gentoo-dev 2010-05-13 21:32:53 UTC
(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
Comment 17 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2010-06-06 23:35:06 UTC
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.
Comment 18 ScytheMan 2011-05-15 23:37:01 UTC
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.
Comment 19 Sébastien Fabbro (RETIRED) gentoo-dev 2011-05-17 18:05:11 UTC
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.
Comment 20 Joerg Bornkessel gentoo-dev 2014-11-08 17:49:12 UTC
By the mass of depended bugs,

why do not add we a virtual package

eg virtual/imagamagick


for the imagemagick vs. graphicsmagick crap ?
Comment 21 Pacho Ramos gentoo-dev 2016-11-30 13:00:27 UTC
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...?
Comment 22 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-30 14:41:23 UTC
@soap, weren't you handling that?
Comment 23 David Seifert gentoo-dev 2016-11-30 14:48:55 UTC
(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.
Comment 24 Pacho Ramos gentoo-dev 2017-02-06 09:15:20 UTC
@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 :|
Comment 25 David Seifert gentoo-dev 2017-02-06 09:19:11 UTC
(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.
Comment 26 Pacho Ramos gentoo-dev 2017-02-07 20:29:35 UTC
Nice, thanks :)
Comment 27 David Seifert gentoo-dev 2017-02-11 13:47:05 UTC
(In reply to Pacho Ramos from comment #26)
> Nice, thanks :)

Please double-check:
https://github.com/gentoo/gentoo/pull/3907
Comment 28 David Seifert gentoo-dev 2017-02-11 19:54:01 UTC
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