Is SSL really a dependant of everything?

[Ryan Schmidt]

On Apr 6, 2020, at 03:39, Christopher Jones wrote:

> On 6 Apr 2020, at 8:42 am, Dave Horsfall wrote:
> 
>> On Mon, 6 Apr 2020, Ryan Schmidt wrote:
>> 
>>> You should not routinely use the -p flag like this.
>> 
>> I did that following advice on this list about a year ago, when some port ("guile"?) that I'd never even heard of would not build.

I do not recommend it. You should almost never use the -p flag. I'm uncertain why we have this flag at all.

Using the -p flag to proceed to build an outdated port P, despite the fact that one of its dependencies D could not be updated, can defeat the purpose of upgrading the port P. One possible result, depending on the reason why port D was updated, if you got a binary of the updated port P, is that port P will then immediately be considered broken and will need to be rebuilt from source. And once the problem with port D is fixed and you're able to upgrade it, you'll then find port P is broken again and will need to be refetched or rebuilt again.

Rev-upgrade can only detect certain kinds of brokenness (i.e. library linkage errors). It's completely possible that by proceeding to update a port P despite failure of updating its dependency D you will introduce an unintended behavior into the upgraded port P that MacPorts cannot detect. Port P will then no longer show as outdated, even though it does not necessarily correspond to what you should have for that version / revision.

You mentioned that you use "port upgrade -p outdated". Note that single-dash / single-letter flags like -p are global and do nothing unless you place them immediately after the command "port", e.g. (but don't do this!) "sudo port -p upgrade foo". In contrast, double-dash / multiple-letter flags like --no-rev-upgrade are specific to each command verb and must be placed after the command verb, e.g. "sudo port -u upgrade --no-rev-upgrade foo".


>>> Do you mean openssl? or libressl? or something else?
>> 
>> openssl-1.1.1f_0+universal.darwin_16.i386-x86_64
> 
> So from the above you can tell you are using the universal variant of the package.
> 
> Looking at
> 
> http://packages.macports.org/openssl/
> 
> you can see these variants used to be built by the buildbots and thus distributed in binary form, however this appears to have stopped for the more recent versions. This is why you had to build it from source, and likely why you are having to build a lot of dependencies from source.
> 
> Why this was done, intentionally or otherwise, I do not know.

A universal package will only be produced by our buildbot when something is committed that requires it.

Three such ports are wine, wine-devel, and wine-crossover. Wine requires 32-bit support which means that on 64-bit systems it requires universal dependencies.

I used to update the wine ports regularly; a new development version of wine would appear every two weeks. So universal packages for all of wine's dependencies would be produced every two weeks.

I haven't been updating the wine ports lately. I intend to get back to doing that.

It would be nice if we always built a universal version of a port if we had ever built a universal version of that port before. However we have not implemented that feature in our buildbot yet. See https://trac.macports.org/ticket/35897#comment:20

If you don't need to use the universal variant (or any other particular variant) of a port, reinstall it with its default set of variants to make it more likely that you will receive a binary package.