Hello Mojca,
thanks for replying!
>> 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's simpler, yes, but why is it `much better'? As far as I
understand, later on I can't simply say
sudo port activate inactive
since the list of inactive ports is much larger due to updates. In
other words, I have to store the list of active packages somewhere.
>> 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.
Hmm. Shouldn't `port' handle such situations gracefully? It gets all
packages to be deactivated as a single call, it thus can reorder as
necessary.
Irrespective of the problems I wonder whether it is a valid approach
to deactivate everything – since `port' started with zero packages at
the very beginning, it should work, right?
> (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.)
Ah, my fault, I was imprecise: `port' complained not being able to
deactivate `libgcc8' because it wasn't active. This implies that
`port' has implicitly already deactivated it and then stumbled over
the direct command to deactivate.
>> Secondly, restarting `port' no longer works; [...]
>
> This is somewhat strange. This is my blind guess [...]
Yes, this is it, I presume. Will work on that soon.
> 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
> :)
Yes, this was explained to me on the list, but I was too lazy to go
that route. Now the issue knocked me down :-) IMHO, the best solution
would be to build a statically linked `port' program that is immune to
DLL problems – AFAIK, most GNU/Linux distributions do exactly that for
the central package manager (zypper, apt, rpm, etc.)
>> * 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 ...)
I want to build `gub', the lilypond packager. Assuming that it works
I want to document how to build. Compiling all lilypond flavours from
scratch (including documentation) takes almost a day (using
approx. 20GByte of disk space), so it is quite important to know what
MacPorts packages must be installed before starting compilation for
obvious reasons.
As an example, I can't directly start `gub' because Lion's python
version is too old. I thus have to install `python' via MacPorts
before I can explore what else is missing.
Werner
