problem with reactivating ports

[Werner LEMBERG]

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