problem with reactivating ports

Mojca Miklavec mojca at macports.org
Sun Jan 13 14:35:29 UTC 2019


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


More information about the macports-users mailing list