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.
