On 2022-04-14, at 3:44 AM, Peter Serocka wrote:
> A "meta-select" can easily provide /opt/local as symlink to the desired
> default tree. Another tiny tool can set up $PATH for users at runtime,
> providing the bin folders from multiple trees (PATH= ...
> $(/opt/local/bin/mp_paths) ...)
So
Hi,
On Thu, Apr 14, 2022 at 04:10:26PM -0500, Ryan Schmidt wrote:
> On Apr 14, 2022, at 14:34, Daniel J. Luke wrote:
> > Once you do step 2, the port command works again (and you should
> > follow the rest of the instructions, but if you're prepared to live
> > with the consequences of things mayb
On Thu, 14 Apr 2022, Daniel J. Luke wrote:
[...]
> > Which prevents further upgrades or installs in the existing tree.
>
> ... until you follow the instructions.
>
> Once you do step 2, the port command works again (and you should follow
> the rest of the instructions, but if you're prepared t
On 2022-04-11 19:10, Jim DeLaHunt wrote:
Hello, MacPorts folks:
I am following the MacPorts wiki "Migration"[1] instructions as I move
from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1
Monterey machine with an arm64 CPU.…
Ahem. The new machine is of course macOS 12.3.1 M
On Apr 14, 2022, at 04:57, Richard L. Hamilton wrote:
> Would use of @loader_path as in @loader_path/../lib or whatever when linking
> binaries (and something similar for linking between libraries within
> MacPorts) not be a big part of making it so the executables and libraries
> didn't embed
On Apr 14, 2022, at 14:34, Daniel J. Luke wrote:
> On Apr 14, 2022, at 2:56 PM, Peter Serocka wrote:
>
>> Error: Current platform "darwin 19" does not match expected platform "darwin
>> 18"
>> Error: If you upgraded your OS, please follow the migration instructions:
>> https://trac.macports.org
> On Apr 14, 2022, at 15:24, chilli.names...@gmail.com wrote:
>
>> Error: Current platform "darwin 19" does not match expected platform "darwin
>> 18"
>> Error: If you upgraded your OS, please follow the migration instructions:
>> https://trac.macports.org/wiki/Migration
>> OS platform mismat
> On Apr 14, 2022, at 14:56, Peter Serocka wrote:
>
>
>
>> On Apr 14, 2022, at 14:10, chilli.names...@gmail.com wrote:
>>
>>
>>
>> Thinking more about upgrading, maybe there's an Xcode version issue?
>> MacPorts requires Xcode's command line tools. Though a newer version of
>> macOS ca
On Apr 14, 2022, at 2:56 PM, Peter Serocka wrote:
>> On Apr 14, 2022, at 14:10, chilli.names...@gmail.com wrote:
> Xcode version mismatch issues do exist in some situations, and I have been
> dealing with those; but my point here is that the port command itself refuses
> to do any further work a
> On Apr 14, 2022, at 14:10, chilli.names...@gmail.com wrote:
>
>
>
> 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,
> On Apr 14, 2022, at 07:54, Peter Serocka wrote:
>
>
>
>> On Apr 14, 2022, at 13:08, chilli.names...@gmail.com 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
>> i
> On Apr 14, 2022, at 13:08, chilli.names...@gmail.com 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 i
> On Apr 14, 2022, at 06:45, Peter Serocka wrote:
>
>
>
>> On Apr 14, 2022, at 11:48, Ryan Schmidt wrote:
>>
>>> On Apr 14, 2022, at 04:34, Peter Serocka wrote:
>>>
>>> Sure. On the other hand -- let me suggest MacPorts to adopt
>>> OS/architecture-specific prefixes by default. Transitio
app bundles produced by Xcode are much more "controlled" than usual packages
that use all kinds of build/make tools... It is virtually impossible to impose
the use of @loader_path from the "top" level where MacPorts is operating...
> On Apr 14, 2022, at 11:57, Richard L. Hamilton wrote:
>
> Wo
> On Apr 14, 2022, at 11:48, Ryan Schmidt wrote:
>
> On Apr 14, 2022, at 04:34, Peter Serocka wrote:
>
>> Sure. On the other hand -- let me suggest MacPorts to adopt
>> OS/architecture-specific prefixes by default. Transitions will benefit, in
>> particular in cases where "some" ports are t
Would use of @loader_path as in @loader_path/../lib or whatever when linking
binaries (and something similar for linking between libraries within MacPorts)
not be a big part of making it so the executables and libraries didn't embed
where the tree lived? There would doubtless be other changes t
On Apr 14, 2022, at 04:34, Peter Serocka wrote:
> Sure. On the other hand -- let me suggest MacPorts to adopt
> OS/architecture-specific prefixes by default. Transitions will benefit, in
> particular in cases where "some" ports are troublesome.
I don't think there's any chance of that happening
> On Apr 14, 2022, at 08:31, Ryan Schmidt wrote:
>
> On Apr 13, 2022, at 03:32, Peter Serocka wrote:
>
>> FWIW, I have found it useful to install MacPorts under a new prefix
>> with every MacOS/Darwin release (like /opt/macports##).
>
> By doing that you'll miss out on being able to receive
On Apr 13, 2022, at 03:32, Peter Serocka wrote:
> FWIW, I have found it useful to install MacPorts under a new prefix
> with every MacOS/Darwin release (like /opt/macports##).
By doing that you'll miss out on being able to receive precompiled binaries
from us and will have to compile everything
FWIW, I have found it useful to install MacPorts under a new prefix
with every MacOS/Darwin release (like /opt/macports##).
This offers a soft transition, as installed stuff
usually keeps working after OS upgrades.
It has even made sense to hack the port command a little bit,
to allow plain q
On Apr 11, 2022, at 21:10, Jim DeLaHunt wrote:
> Might the presence of "archs='x86_64'" cause the restore_ports.tcl script to
> ask for +universal variants on the new computer?
>
> Should I perhaps null out the value "x86_64" from the archs entries in my
> installed ports list? i.e. turn
Hi,
Speaking only for myself, I generally suggest *not* using the
restore_ports.tcl script. When I migrate to a new OS I generate the list
of installed ports *and* requested ones, and follow the instructions as
far as wi[ping out my old ports prior to the update.
However, when restoring the
Hello, MacPorts folks:
I am following the MacPorts wiki "Migration"[1] instructions as I move
from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1
Monterey machine with an arm64 CPU. I got stuck with a bug in the tiff
port, which fails during destroot under the +universal vari
23 matches
Mail list logo
