conflicting versions of gdk-pixbuf2

[Ryan Schmidt]

On Mar 22, 2021, at 11:30, Murray Eisenberg wrote:

> I’m installing the non-MacPorts application coq “platform”, which uses various MacPorts ports and installs those not already installed through the usual MacPorts process.

Curious... I don't know that I've encountered any other software distributing itself this way. It might be better if they used a single distribution method: either offer everything in MacPorts, or else offer everything outside of MacPorts, rather than this hybrid approach. We expect the user to be in control of what they install with MacPorts; we do not expect other software to drive MacPorts for the user.


> One of those it needs to install is gtk3, but that installation aborts because it "failed to configure gtk3: gdk-pixbuf2 must be installed without +x11.”
> 
> The trouble is that I already have gdk-pixbuf2 +x11 installed, which is uses for inkscape (and several packages on which inkscape depends).
> 
> I know that inkscape can be installed with +quartz variant instead of +x11, but I think that will lead to a rabbit-hole of problems for other packages that depend on gdk-pixbuf2 and on which ImageMagick+x11 in turn depends.
> (In turn, pstoedit depends on ImageMagick, and octave depends on pstoedit; specifically, I have octave @6.2.0_1+accelerate+app+docs+gfortran+graphicsmagick+qt5+sound+sundials).
> 
> How might it be possible to proceed ?

gtk can be built for x11 or quartz but not both. You have to choose. This choice infects other ports that depend on gtk, therefore you should decide before you install any ports whether you want x11 or quartz, and you should not change your mind unless you uninstall all ports and start over. If you choose quartz, make sure all ports use that choice by adding +quartz to your variants.conf.

If you need to have some ports that use x11 and some that use quartz, then you should have separate MacPorts installations for x11 and quartz. Since x11 is our default, I recommend making /opt/local your x11 prefix (so that you can get binaries from us of x11 ports) and some other directory (maybe /opt/quartz) your quartz prefix (since you'll have to build quartz ports from source anyway). You would then need to tell coq "platform" to use that other MacPorts prefix. (Maybe its documentation will say how to do that.)

It would be nice if we used subports instead of variants for the x11/quartz choice. Then this problem would not exist since x11 and quartz versions of software could coexist. But subports did not exist when x11/quartz variants started appearing in MacPorts. I still think we should change it but it will be a huge project to do so.