Re: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?
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.
Re: gimp open with
Please continue to Reply All so that the conversation stays on the mailing list.
On May 31, 2022, at 18:40, James wrote:
> On 1 Jun 2022, at 7:19 am, Ryan Schmidt wrote:
>
>> I have not used gimp often enough to be familiar with the option you're
>> referring to so I'm not sure I can advise you properly. However it may be
>> significant that gimp can be compiled either in x11 mode or with a native
>> macOS user interface, which we refer to as quartz mode. It may be the case
>> that the disk image distributed by the developers of gimp was compiled in
>> quartz mode, while the default in MacPorts is x11 mode, which may account
>> for some of the discrepancies you're experiencing. You can install gimp in
>> quartz mode with MacPorts by using the +quartz variant, however if you wish
>> to switch from x11 mode to quartz mode you should decide to do so for all of
>> your installed ports at once, and it is recommended to uninstall all ports,
>> edit variant.conf to add +quartz, and then reinstall the ports you want.
>> That way, ports that have quartz variants that require some of their
>> dependencies to have quartz variants enabled will get built correctly.
>>
>> In MacPorts gimp in x11 mode, I just tried saving a file, and then I tried
>> save-as with the same filename, and it prompted me about whether I wanted to
>> overwrite the existing file. If this is not the capability you're seeking,
>> please clarify.
>
> We just had a massive lightning strike that took out lots (apple tv, ethernet
> on my mac, printer, nucs, blackmagic boxes, usb keyboard ...) so I might be
> confused in my overloaded state :-) The real issue is the open event.
>
> I can't find how to remove a single port, google has oodles to say on how to
> remove ALL ports, but nothing about 1.
To uninstall a port named foo and a port named bar, "sudo port uninstall foo
bar".
You can also specify pseudo portnames like "installed" or "inactive" ("sudo
port uninstall inactive").
> I will compile gimp with +quartz but most of my ports do use X11 so I don't
> want quartz versions. SSH from other machines!
> nomachine and remote desktop from other macs are cludgy.
I don't think you will have success attempting to install gimp2 with +quartz
while retaining the +x11 variant of other ports. In particular, gimp2 and gtk2
will need to be installed with the same variant (either +quartz or +x11), and
whatever variant you install gtk2 with will need to be set on all other ports
that use gtk2. That's why we suggest to decide which variant you want before
installing any ports (or uninstall all ports and reinstall if you change your
mind).
If you want to use some ports with +x11 and some with +quartz, one
oft-suggested idea is to keep your main MacPorts installation at /opt/local
using +x11 (so that you can receive binaries from us) and build a second
MacPorts installation from source in a different prefix (/opt/quartz, say) and
configure that one with +quartz.
Ideally we would reengineer this situation so that quartz and x11 things could
coexist. It's been a long-term wish that nobody worked on yet, though Chris
says he will work on it.
Re: Port tree not syncing
On Jun 2, 2022, at 20:44, Craig Treleaven wrote: > I’m a port maintainer…but I’m having a user problem. For some weeks now, > ‘sudo port selfupdate’ has not been properly updating my local ports tree(s) > on my main Mac. About 2 weeks ago, I was going to post a question about this > but then I ran ‘sudo port -d selfupdate’ and it seemed that all the missed > updates were now caught up. I put it down to gremlins in the ether but then > I noticed recently that I had no outdated ports when I knew that there should > be several. I tried ’sudo port -d sync’ with the same result, ie no updates. > > Obviously, ’sudo port selfupdate’ has worked flawlessly for me for quite a > few years. TTBOMK, I haven’t changed anything relevant on my side. I’m > overdue to update my OS version (I’m on 10.15.7). > > I’ve pasted the debug log from ’sudo port -d sync’ in case that shows > something useful: > > https://paste.macports.org/69b104de0e93 > > BTW, I have another older Mac that also has MacPorts installed. ’sudo port > selfupdate’ continues to work as expected on that machine. > > Suggestions on what’s wrong and how to fix it? From that log, looks like you have two sources configured: the standard rsync one, which looks like it updated ok, and one you created at file:///Users/craigtreleaven/mp/macports-ports, which looks like it contains a full collection of ports and did not get updated on that sync. Presumably file:///Users/craigtreleaven/mp/macports-ports is the one marked as default in sources.conf so any ports present there (which is presumably all of them) override those in the rsync tarball, which is why nothing is shown as outdated. So there's no reason for your sources.conf to continue to list the rsync tarball since those ports won't be used. You can delete the things related to ports in /opt/local/var/macports/sources too. (The ones related to base can stay, or will be recreated when you selfupdate.) What is file:///Users/craigtreleaven/mp/macports-ports? Is it a git clone of the macports-ports repository? Ours or your fork? What happens if you try to update it with git manually? Is there an error? Or is perhaps a branch other than master checked out?
Port tree not syncing
Hi: I’m a port maintainer…but I’m having a user problem. For some weeks now, ‘sudo port selfupdate’ has not been properly updating my local ports tree(s) on my main Mac. About 2 weeks ago, I was going to post a question about this but then I ran ‘sudo port -d selfupdate’ and it seemed that all the missed updates were now caught up. I put it down to gremlins in the ether but then I noticed recently that I had no outdated ports when I knew that there should be several. I tried ’sudo port -d sync’ with the same result, ie no updates. Obviously, ’sudo port selfupdate’ has worked flawlessly for me for quite a few years. TTBOMK, I haven’t changed anything relevant on my side. I’m overdue to update my OS version (I’m on 10.15.7). I’ve pasted the debug log from ’sudo port -d sync’ in case that shows something useful: https://paste.macports.org/69b104de0e93 BTW, I have another older Mac that also has MacPorts installed. ’sudo port selfupdate’ continues to work as expected on that machine. Suggestions on what’s wrong and how to fix it? Thanks, Craig
Segregated subports (was Re: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?)
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?
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?
> 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?
> 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
