> On Apr 14, 2022, at 07:54, Peter Serocka <[email protected]> wrote:
> 
> 
> 
>> On Apr 14, 2022, at 13:08, [email protected] wrote:
>> 
>> 
>> 
>> 
>> I don't get it. What is stopping MacPorts users that don't use custom 
>> prefixes from using network drives? A custom prefix and hierarchy will not 
>> isolate anything.  A package manager isn't much of a package manager if it 
>> leaves you in dependency hell... MacPorts solved this already just by being 
>> a package manager. Port activation/deactivation is not a bug, it's a 
>> feature, and really not much of  headache. Upgrading macOS will not do 
>> anything to /opt. An architecture change means another, separate distinct 
>> system, which will need it's own OS and MacPorts install.
>> 
>> I'm not seeing the fatal problems your solution of custom prefixes hopes to 
>> solve. 
> 
> No fatal problems to overcome, just benefits I have been appreciating.
> 
> Network drives were automounted to a different place than /opt; and 
> /opt/local -- being a quite generic name by itself -- was already taken by 
> other stuff in that specific corporate environment :(
> 
> "Isolating" in the sense of keeping e.g. qt-related or rust-related stuff in 
> different trees,
> to adopt different update cycles.
> 
> Again I find side-by-side installations of alternatives are easier to handle 
> than activations, but of cause your miles may vary. Nothing wrong with that.
> 
>> Upgrading macOS will not do anything to /opt
> 
> Well under /opt/local, installed ports usually keep working, but the port 
> command will refuse to run even simple queries and you have to start all 
> over. With a new prefix tree transitions cam be performed gradually; and you 
> keep a fall-back in place. I just happen to like that -- so why not 
> discussing it in the light of possible binary distributions when that 
> suggestion was made? I understand my proposal doesn't resonate too well with 
> you; anyway, thanks a heap for your efforts!
> 

Conflicting directory names... that's a tough one.

Sorry, I was thinking of "isolating," as requiring sandbox, jail, container, 
etc. I believe you mean "organizing."

Thinking more about upgrading, maybe there's an Xcode version issue? MacPorts 
requires Xcode's command line tools. Though a newer version of macOS can run 
older and outdated versions of Xcode, after upgrading the OS, the user will 
often find Xcode greyed out with the circle with the line through it. Upgrading 
macOS didn't used to do this, but it apparently does now. There are steps (or 
tricks) available now to get older Xcode versions working with a newer 
mismatched macOS version. But I bet that's why port is choking after upgrade: 
maybe port still works, but the upgrade broke Xcode, so port chokes. A wild 
guess.


Reply via email to