Re: Port tree not syncing

[Craig Treleaven]

> On Jun 2, 2022, at 10:19 PM, Ryan Schmidt  wrote:
> 
> 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?
> 

Hi Ryan:

I seem to have it fixed.  I guessed that PortIndex (in 
/Users/craigtreleaven/mp/macports-ports) might be damaged so I moved it aside 
temporarily and ran ’sudo port -d sync’.  After it chugged away, it reported a 
whole bunch of ports were outdated.  

In the past, I’ve had to blow away my git clone (not fork) from time to time 
when I messed up something.  That’s the reason I’ve kept both the standard 
MacPorts-installed tree and the git clone.  Is there any harm in having both?

Thanks,

Craig

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