problem with reactivating ports

[Werner LEMBERG]

Hello Ryan!


> Do you need those old inactive versions?  If not, you could
> uninstall the inactive ports before beginning the exercise.

Is there a safe command to uninstall all inactive ports in one rush?

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

Verified thanks, after building `port' with an external curl library
(I used https://try.gitea.io/donbright/lm for my Lion box).

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

OK, thanks for the info.

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

Well, this is true for MacOS versions still supported by Apple, but
not for older ones.  I'm glad that MacPorts is on the conservative
side.  For the young kids who always use the newest stuff there is
Homebrew...

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

Lesson learned :-)

> 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

Yes!  Actually, I don't understand the many objections raised in the
ticket.  For older MacOS versions, `macports-base' could be configured
to build private, statically linked libcurl & ssl versions only once,
namely for `port' itself – let's call the resulting binary
`port-bootstrap' –, and there would be no need to always use the most
recent and most secure versions since you only use it to start
MacPorts package management.  The first action could be then to
download a `port' package (which doesn't exist yet) that uses the most
recent libraries, and which receives the usual updates.  If someone is
going to delete that `port' package accidentally, the original
`port-bootstrap' binary would be still available as a backup.

>> 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.  [...]
> 
> I don't think there's a good way to figure that out automatically.
> [...]

OK, thanks.


    Werner