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

[Ryan Schmidt]

On Jun 5, 2022, at 12:42, Jim DeLaHunt wrote:
> 
>>> …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.)

It's documented frequently on this mailing list. I don't know if it is 
documented in a more permanent place like the wiki or guide.


> The place where these instructions would have done me good is in the 
> Migration instructions: .

The migration instructions are intended to help you move an existing MacPorts 
installation to a new system, preserving it the way it was installed as much as 
possible, so any advice about what variants you should choose seems like it 
would be misplaced in that document.


> 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.

The x11/quartz distinction is primarily significant for gtk2/gtk3 since those 
ports can currently only be built for one or the other, and which flavor of gtk 
you use dictates which flavor of all the ports that depends on gtk you can use. 
Chris wishes to begin work on making these available as subports instead of 
variants so that they could coexist and this limitation would then disappear.

ffmpeg's x11 variant does not have anything to do with gtk, so you can make 
that decision separately from the ports that do use gtk. ffmpeg does use 
libsdl2 and, if you use ffmpeg's x11 variant, it requires that you use 
libsdl2's x11 variant as well. It will let you know about that if you haven't 
already done that.

Re: 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  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" .
> 
> 
>> 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 
> . 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: .
> 
> 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
> 
> 

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

[Jim DeLaHunt]

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" .




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 
. 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: .


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

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

[Ryan Schmidt]

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.

You can add a variant to an already-installed port by using "sudo port upgrade 
--enforce-dependencies someport +somevariant".


> I just tried to `install gimp +quartz`. This failed several times, each time 
> with errors about some recursive dependency of gimp requiring its own 
> dependency to be installed with a +quartz variant, but the port was already 
> installed without the +quartz variant` commands explicitly.
> 
> The specific ports in question are:
> 
> gimp +quartz, 
>   which depends on gimp-lqr-plugin,
> which depends on gimp2 +quartz — but it was installed without that 
> variant,
>   which depends on gtk-osx-application-gtk2,
>   and depends on gtk2 +quartz — but it was installed without that variant,
>   and depends on py27-pygtk +quartz — but it was installed without that 
> variant,
> which depends on libglade2,
>   which also depends on gtk2 +quartz
> 
> So concretely, install gimp +quartz failed because gimp2 was installed 
> without +quartz. 
> A manual install gimp2 +quartz failed because gtk2 was installed without 
> +quartz.
> A manual install gtk2 +quartz succeeded, but led to 5 broken ports. 
> Rebuilding those broken ports failed at py27-pygtk because an in-progress 
> build of gimp2 had conflicting variants "+python27" vs "+python27+quartz". 
> A clean of gimp2, followed by a second manual install gimp2 +quartz 
> succeeded, but led to 4 broken ports. Rebuilding those broken ports failed at 
> py27-pygtk because gtk2 was installed with +quartz (actually, without the 
> conflicting variant +x11). 
> An uninstall py27-pygtk (despite gimp2 depending on it), followed by a clean 
> py27-pygtk, succeeded.
> A manual install py27-pygtk +quartz succeeded, but led to 2 broken ports. 
> Rebuilding those broken ports succeeded.
> 
> 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.

Segregated subports (was Re: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?)

[Langer, Stephen A. (Fed) via macports-users]

On 6/2/22, 12:11 PM, "macports-users on behalf of Eric Gallager via 
macports-users"  wrote:

> Ultimately this nonsense will all be eliminated, by migrating from 
variants to segregated subports. That’s a big effort, given the number of ports 
involved. But it’s something I’m finally starting to work on, as it also 
frustrates me as the maintainer!
>
> The first big win was completed a few days ago, and that’s segregation of 
the various ‘gtk-osx-application-xxx’ subports. This allows users to finally be 
able to install Quartz apps for both gtk2 and gtk3 side-by-side, which wasn’t 
possible previously. (So folks can have GIMP Quartz and Inkscape Quartz 
installed at the same time, for example.)
>
> More to follow over the coming weeks, but we’re finally making slow and 
steady progress!

> Cheers,
> -Chris


How do segregated subports work, from the user's perspective?  I have been 
somewhat clumsily maintaining two macports installations, one for x11 and one 
for quartz, so that I could test programs in both environments.  Will 
segregated subports make that easier?  That would be great.

Thanks,
 
-- Steve

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

[Eric Gallager via macports-users]

On Thu, Jun 2, 2022 at 8:33 AM Christopher Nielsen
 wrote:
>
> > 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.
>
> Your frustration is understandable, as this can be a bit painful if you 
> already have non-Quartz versions of any dependencies installed. However, I’m 
> reluctant to tweak those at this point, as it’s not an easy problem to solve 
> as-is.
>
> Ultimately this nonsense will all be eliminated, by migrating from variants 
> to segregated subports. That’s a big effort, given the number of ports 
> involved. But it’s something I’m finally starting to work on, as it also 
> frustrates me as the maintainer!
>
> The first big win was completed a few days ago, and that’s segregation of the 
> various ‘gtk-osx-application-xxx’ subports. This allows users to finally be 
> able to install Quartz apps for both gtk2 and gtk3 side-by-side, which wasn’t 
> possible previously. (So folks can have GIMP Quartz and Inkscape Quartz 
> installed at the same time, for example.)
>
> More to follow over the coming weeks, but we’re finally making slow and 
> steady progress!

Note that the bug for tracking this progress is ticket 60511, for
anyone interested: https://trac.macports.org/ticket/60511

> Cheers,
> -Chris

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

[Ken Cunningham]

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

propagate to dependencies?

Yes. You demonstrated that already when you tried to install gimp +quartz and 
it passed that down to deps.

overrule existing variants?

No. 

If you already have a port installed with a certain variant, and then you try 
to install that port again with a conflicting variant (especially 
automatically), MacPorts doesn’t know what you really want to do exactly. So it 
asks you to deactivate or uninstall the one you have installed first, rather 
than doing it automatically for you.

Design choice, most would support, not everyone.

You can find the ports you have installed as x11 pretty easily (port -v 
installed | grep x11) and deactivate them, or just deactivate all your ports if 
you prefer and then install gimp +quartz and away you go.


You can add +quartz to “variants.conf” to make that a global default even if 
you forget setting if you like.

HTH,

K

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

[Christopher Nielsen]

> 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.

Your frustration is understandable, as this can be a bit painful if you already 
have non-Quartz versions of any dependencies installed. However, I’m reluctant 
to tweak those at this point, as it’s not an easy problem to solve as-is.

Ultimately this nonsense will all be eliminated, by migrating from variants to 
segregated subports. That’s a big effort, given the number of ports involved. 
But it’s something I’m finally starting to work on, as it also frustrates me as 
the maintainer!

The first big win was completed a few days ago, and that’s segregation of the 
various ‘gtk-osx-application-xxx’ subports. This allows users to finally be 
able to install Quartz apps for both gtk2 and gtk3 side-by-side, which wasn’t 
possible previously. (So folks can have GIMP Quartz and Inkscape Quartz 
installed at the same time, for example.)

More to follow over the coming weeks, but we’re finally making slow and steady 
progress!

Cheers,
-Chris

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

[Andrew Udvare]

Unfortunately it does not propagate. You can set global variants in
macports.conf

On Wed, Jun 1, 2022, 18:32 Jim DeLaHunt 
wrote:

> Should I expect a +quartz variant to propagate to dependencies, and
> overrule existing variants?
>
> I just tried to `install gimp +quartz`. This failed several times, each
> time with errors about some recursive dependency of gimp requiring its own
> dependency to be installed with a +quartz variant, but the port was already
> installed without the +quartz variant` commands explicitly.
>
> The specific ports in question are:
>
> gimp +quartz,
>   which depends on gimp-lqr-plugin,
> which depends on gimp2 +quartz — but it was installed without that
> variant,
>   which depends on gtk-osx-application-gtk2,
>   and depends on gtk2 +quartz — but it was installed without that
> variant,
>   and depends on py27-pygtk +quartz — but it was installed without
> that variant,
> which depends on libglade2,
>   which also depends on gtk2 +quartz
>
> So concretely, install gimp +quartz failed because gimp2 was installed
> without +quartz.
> A manual install gimp2 +quartz failed because gtk2 was installed without
> +quartz.
> A manual install gtk2 +quartz succeeded, but led to 5 broken ports.
> Rebuilding those broken ports failed at py27-pygtk because an in-progress
> build of gimp2 had conflicting variants "+python27" vs "+python27+quartz".
> A clean of gimp2, followed by a second manual install gimp2 +quartz
> succeeded, but led to 4 broken ports. Rebuilding those broken ports failed
> at py27-pygtk because gtk2 was installed *with* +quartz (actually,
> without the conflicting variant +x11).
> An uninstall py27-pygtk (despite gimp2 depending on it), followed by a
> clean py27-pygtk, succeeded.
> A manual install py27-pygtk +quartz succeeded, but led to 2 broken ports.
> Rebuilding those broken ports succeeded.
>
> 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.
>
> Thank you for your advice!
> —Jim DeLaHunt
>
>
> --
> .--Jim DeLaHunt, Vancouver, Canada
>
>

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

[Jim DeLaHunt]

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


I just tried to `install gimp +quartz`. This failed several times, each 
time with errors about some recursive dependency of gimp requiring its 
own dependency to be installed with a +quartz variant, but the port was 
already installed without the +quartz variant` commands explicitly.


The specific ports in question are:

gimp +quartz,
  which depends on gimp-lqr-plugin,
    which depends on gimp2 +quartz — but it was installed without that 
variant,

  which depends on gtk-osx-application-gtk2,
  and depends on gtk2 +quartz — but it was installed without that 
variant,
  and depends on py27-pygtk +quartz — but it was installed without 
that variant,

    which depends on libglade2,
  which also depends on gtk2 +quartz

So concretely, install gimp +quartz failed because gimp2 was installed 
without +quartz.
A manual install gimp2 +quartz failed because gtk2 was installed without 
+quartz.
A manual install gtk2 +quartz succeeded, but led to 5 broken ports. 
Rebuilding those broken ports failed at py27-pygtk because an 
in-progress build of gimp2 had conflicting variants "+python27" vs 
"+python27+quartz".
A clean of gimp2, followed by a second manual install gimp2 +quartz 
succeeded, but led to 4 broken ports. Rebuilding those broken ports 
failed at py27-pygtk because gtk2 was installed *with* +quartz 
(actually, without the conflicting variant +x11).
An uninstall py27-pygtk (despite gimp2 depending on it), followed by a 
clean py27-pygtk, succeeded.
A manual install py27-pygtk +quartz succeeded, but led to 2 broken 
ports. Rebuilding those broken ports succeeded.


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.


Thank you for your advice!
    —Jim DeLaHunt


--
.--Jim DeLaHunt, Vancouver, Canada