libgcc9 and other ports that will never build on my system

[chilli.namesake at gmail.com]

>> port upgrade outdated and not \( badport1 or badport2 \)

that works perfect, thank you!

feel free to mock me, I deserve it.

> On Sep 12, 2022, at 15:19, chilli.namesake at gmail.com wrote:
> 
> No, I got it. Ignore.
> 
> And thank you all.
> 
>> On Sep 12, 2022, at 15:16, Richard L. Hamilton <rlhamil at smart.net> wrote:
>> 
>> You can say
>> 
>> port upgrade outdated and not badport1
>> 
>> or even
>> 
>> port upgrade outdated and not \( badport1 or badport2 \)
>> 
>> 
>> although if badport1 (badport2, etc) is depended on by something else being upgraded, it will probably get upgraded too (and fail, I suppose).
>> 
>> You can upgrade a port without upgrading what it depends on with
>> 
>> port -n upgrade outdated and not badport1
>> 
>> but AFAIK, that’s usually NOT recommended except more rarely and specifically than something as broad as port upgrade outdated, to work around a specific problem (for which I gather you should have checked for a ticket and if it didn’t exist already, filed one). Although if dependencies other than badport1 are also included in “outdated", I guess they’ll get updated too, if not necessarily in the ideal order.
>> 
>> although when I say that, I’m kind of saying do what I say and not what I do, because I wing it a bit just to get through the daily update ritual. My usual looks a bit like the line above with the parenthesized list of what not to update, except rather longer.
>> 
>> 
>>>> On Sep 12, 2022, at 3:02 PM, chilli.namesake at gmail.com wrote:
>>> 
>>> 
>>> Yes, you got it. How do I command MacPorts to upgrade all outdated ports "and not" this whatever troublesome port?  Is there a way? If you just told me, you'll have to be less subtle.
>>> 
>>>>> On Sep 12, 2022, at 14:00, Bill Cole <macportsusers-20171215 at billmail.scconsult.com> wrote:
>>>> On 2022-09-12 at 12:04:41 UTC-0400 (Mon, 12 Sep 2022 12:04:41 -0400)
>>>> <chilli.namesake at gmail.com>
>>>> is rumored to have said:
>>>> 
>>>>> Thanks for catching that.
>>>>> 
>>>>> From my macports.conf file:
>>>>> # CPU architecture to target. Supported values are "ppc", "ppc64",
>>>>> # "i386", "x86_64", and "arm64". Defaults to:
>>>>> # - Mac OS X 10.5 and earlier: "ppc" on PowerPC, otherwise "i386".
>>>>> # - Mac OS X 10.6 - 10.15: "x86_64" on 64-bit Intel, otherwise "i386".
>>>>> # - macOS 11 and later: "arm64" on Apple Silicon, otherwise "x86_64".
>>>>> build_arch              x86_64
>>>>> 
>>>>> 
>>>>> thus, I was not trying to build for i386, I've specified x86_64
>>>> 
>>>> If for some reason you had built it with the 'universal' variant you could also end up rebuilding it for both. But as I said, I don't think this is the point of attack.
>>>> 
>>>>> I find it difficult to believe MacPorts has no control over what it is updating.
>>>>> MacPorts upgrade command obviously has some way to know what ports have updates available:
>>>>> 
>>>>> port upgrade outdated
>>>>> 
>>>>> The outdated argument tells upgrade what to update. I was hoping it would be something simple like
>>>>> 
>>>>> port upgrade outdated -libgcc9
>>>> 
>>>> Like I said...
>>>> 
>>>> 
>>>>>>> On Sep 12, 2022, at 09:29, Bill Cole <macportsusers-20171215 at billmail.scconsult.com> wrote:
>>>> [...]
>>>> 
>>>>>> 3. "sudo port upgrade outdated and not libgcc9" should work, but it will leave everything dependent on libgcc9 at older versions.
>>>> 
>>>> The only difference from your hypothetical command is 'and not' instead of '-'
>>>> 
>>>> 
>>>> -- 
>>>> Bill Cole
>>>> bill at scconsult.com or billcole at apache.org
>>>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>>>> Not Currently Available For Hire
>>> 
>>