problem with reactivating ports

[Ryan Schmidt]

On Jan 13, 2019, at 10:03, Werner LEMBERG wrote:

> 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.

What you did -- recording active files into a text file for later reactivation -- is fine, and is similar to what we recommend users do in our migration instructions.

Do you need those old inactive versions? If not, you could uninstall the inactive ports before beginning the exercise. However, keeping a record in a text file, as you did, is still a good idea, in case anything goes wrong and the complete set of ports doesn't get reactivated.


>>> 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.

As far as I know, MacPorts does reorder the ports into the correct order.


> 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?

Yes, deactivating all ports should work successfully. We do that on the buildbot workers after every build.


>> (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.

I have seen this error with libgcc8 on the buildbot workers as well. I think we probably forgot a step back when the libgcc7/libgcc8 ports were introduced. For example, we may have forgotten to increase the revision of all the ports that depend on those ports.


>> 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.)

Of course, macOS is not GNU/Linux and there are some differences. For example, whereas GNU/Linux uses its package manager to install everything, macOS comes with libraries like libcurl that are not managed by a package manager and we use them. There is no need to link with them statically, nor do we want to, for all the usual reasons: If that library is ever updated by Apple, we would not benefit from that update.

The problem only arises when you do something unsupported, like linking MacPorts to libraries it itself installed. Please don't do that! :)

I continue to believe that we should bundle a recent version of curl and libressl with MacPorts to avoid the too-old-openssl problem that we see on older macOS systems, but we have not reached consensus that we want to do that. See https://trac.macports.org/ticket/51516


>>> * 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.

I don't think there's a good way to figure that out automatically. It's basically the task we have whenever we add a new port to MacPorts. Somebody has to figure out the dependencies, and it's a manual process.

When adding a port, there is the possibility of using trace mode (sudo port -d install ...) wherein MacPorts will hide files that don't belong to dependencies; the resulting error messages you might see can suggest to you which dependencies are missing. If you can make a Portfile for gub, you can then use trace mode as part of your dependency discovery mechanism.