>> 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, [email protected] wrote:
> 
> No, I got it. Ignore.
> 
> And thank you all.
> 
>> On Sep 12, 2022, at 15:16, Richard L. Hamilton <[email protected]> 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, [email protected] 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 
>>>>> <[email protected]> wrote:
>>>> On 2022-09-12 at 12:04:41 UTC-0400 (Mon, 12 Sep 2022 12:04:41 -0400)
>>>> <[email protected]>
>>>> 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 
>>>>>>> <[email protected]> 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
>>>> [email protected] or [email protected]
>>>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>>>> Not Currently Available For Hire
>>> 
>> 

Reply via email to