Dear Werner, On Sun, 13 Jan 2019 at 14:26, Werner LEMBERG wrote: > > I wanted to compile a project under MacPorts, and at the same time I > wanted to protocol what MacPorts packages must be installed in advance > before starting compilation. My glorious idea was to say > > port echo active > macports.active > sudo port deactivate `cat macports.active` > > to deactivate all MacPorts packages. I tried with the `-y' flag in > advance, just to be sure...
I understand the first command, but a much better way for the second one would be sudo port deactivate active > It seems now that this was actually a bad idea. First of all, `port' > aborted in the middle, talking about not being able to deactivate > `libgcc8' (which is on the `macports.active' list). I'm not really sure, but one thing that might happen is that the list of ports to be deactivated comes in wrong order. If B depends on A and you call sudo port deactivate A B then I might fail to deactivate since port is processing them in the same order as they are written and complains that B depends on A, so A cannot be deactivated unless you force it or run it in a recursive way. (Reading further, another reason could be that the ports you tried to deactivate cannot be deactivated as they are needed for the port command itself.) > Secondly, > restarting `port' no longer works; it complains as follows > > dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6): > Library not loaded: /opt/local/lib/libcurl.4.dylib > Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib > Reason: Incompatible library version: > Pextlib.dylib requires version 10.0.0 or later, > but libcurl.4.dylib provides version 7.0.0 This is somewhat strange. This is my blind guess / speculation of what you did (I might be wrong). 10.7 became nearly hopeless with respect to fetching the sources (distfiles) after the servers started requiring a newer version of SSL protocol than what 10.7 can handle by default. So you probably recompiled MacPorts with something like --with-curl=/opt/local, but making a self-reference, and you ended up with a chicken-and-egg problem? > As a first aid I tried to re-install `port' from `macports-base', but > I still get this error. > > My questions. > > * How can I restore (i.e., re-activate) all installed MacPorts > packages? Given that I'm on Lion, I would *really* avoid > recompiling everything from scratch... If you want to avoid recompiling the ports themselves, it would probably make most sense to recompile macports (without --with-curl=/opt/local, or perhaps with another curl that's installed elsewhere) and run the port command again. If you want to use a different libcurl, you could install that libcurl somewhere else. You can install two parallel macports (just make sure that you configure it properly to avoid clashes in /Applications/MacPorts, disable the services etc.) and then use one of them just as "supporting system" for the other one. We would have fixed this long ago if it wasn't for the chicken-and-egg issue :) > * Is there a simple way to protocol needed MacPorts packages? Needed by/for what? You can list recursive dependencies, inside the port you can run trace mode to make sure that no other files are used, listing active packages is possible (but note that you'll probably end up with build dependencies as well if you are building from source ...) Mojca