Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?

[Richard L. Hamilton]

The x11 (and perhaps quartz) variants do not all behave similarly.

ffmpeg is a command line program for conversions and filtering of audio and video; it just has an optional ability to display video, but only on x11;  presumably nobody ever wrote a quartz display alternative for it. But some quartz program that was simply using ffmpeg for conversions and not for display, could do so regardless of that.

Some ports may be able to be built with both +x11 and +quartz; but with others, those may be mutually exclusive or one might be missing.

Since ports originate as separate projects from separate creators, anything that the packaging into MacPorts does to make them APPEAR more uniform is a somewhat fragile illusion - meaning that to some degree or another (perhaps even with the new/ongoing alternative to variants) one sometimes has to know more than one might wish to about how it all works. In routine cases, the illusion might be helpful, but when going beyond the defaults, you may have to know more.

That can also be the case when one tries to manage a bunch of very different systems (Windows, macOS, Linux of various distros, etc, and not all of each even of the same version); one can build tools that in the routine case hide some differences, but when things get interesting, one still needs to look at the fake wizard behind the screen.

> On Jun 5, 2022, at 1:42 PM, Jim DeLaHunt <list+macports-users at jdlh.com> wrote:
> 
> Thank you for the reply, Ryan. This is very helpful.
> 
> On 2022-06-02 19:33, Ryan Schmidt wrote:
>> On Jun 1, 2022, at 17:31, Jim DeLaHunt wrote:
>> 
>>> Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?
>> Variants specified on the command line when installing a port propagate to any dependencies that have not yet been installed. They do not propagate to any dependencies that have already been installed.
> 
> That is good to know, thanks.
> 
> I looked at the Guide to see if this behaviour was described. In my opinion it is not described adequately. I've opened a ticket against the Guide, " Guide 3.2.1: Say that variant specification on port install does not overrule existing ports" <https://trac.macports.org/ticket/65299>.
> 
> 
>> You can add a variant to an already-installed port by using "sudo port upgrade --enforce-dependencies someport +somevariant".
> 
> Clever!  I see that this is documented in <https://guide.macports.org/#using.port.upgrade>. I had not noticed that. I guess I have not read the Guide diligently.
> 
> 
>>> …Thus I succeeded in fumbling my way through installing gimp +quartz despite dependencies already present with the wrong variants, but it was a bit messy and confusing. Should I expect MacPorts to do a better job with this situation?  If so, maybe I should file a ticket against some of these ports, to see if portfile changes would avoid the problems.
>> This undesirable experience is why we recommend users choose whether to use +x11 or +quartz before installing any ports, or uninstall all ports and reinstall them if changing one's mind after having installed ports.
> 
> Interesting! Where is this advice documented? I certainly did not know it before. (But them, I guess I have not read the Guide diligently.) The place where these instructions would have done me good is in the Migration instructions: <https://trac.macports.org/wiki/Migration>.
> 
> I just looked. I have 27 ports with +x11 variants specified. 4 of those ports have +quartz+x11: cairo, cairomm, pango, pangomm. For all 4 of them, +x11 and +quartz appear to be default variants, so I suppose they can coexist. But that leaves me with 23 ports with +x11 to deal with. At least some of them (e.g. ffmpeg) have no +quartz variant. Can such ports coexist as +x11 variants with the rest of a collection of +quartz variant ports?
> 
> I see my port gtk3 is installed as +x11 but not as +quartz. I suspect that is not what I want. Thank you for the heads-up.
> 
> Thank you again for the explanation. Best regards,
>     —Jim DeLaHunt
> 
>