MacPorts 2.8.0-beta1 now available for testing
Fred Wright
fw at fwright.net
Sat Oct 15 02:20:21 UTC 2022
On Sat, 15 Oct 2022, Joshua Root wrote:
> On 2022-10-14 18:13 , Ken Cunningham wrote:
>> the only other thing I noticed was that these helpful pre-fetch messages
>> were no longer being displayed:
>>
>> https://github.com/macports/macports-ports/blob/c7a8d3cf75b8b48a90139cbb35e385bb7bcbd165/x11/xorg-server/Portfile#L103
>> <https://github.com/macports/macports-ports/blob/c7a8d3cf75b8b48a90139cbb35e385bb7bcbd165/x11/xorg-server/Portfile#L103>
>>
>>
>> Instead there was just a message saying the build was known to fail, but
>> try anyway?
>>
>> But the instructions about what to actually do are gone now…
>>
>> Perhaps no way around that?
>
> In that particular case, the solution is to set `replaced_by
> xorg-server-legacy` instead of erroring in pre-fetch. As of 2.8, replaced_by
> will be followed when installing as well as when upgrading.
IMO, it should ask before following replaced_by, since replaced_by is
sometimes a matter of opinion. For example, sometimes "port X is replaced
by port Y" really means "We don't want to bother supporting port X any
more, so you should use port Y instead; if it doesn't meet your needs then
that's too bad."
> I can see why the ability to give an explanation more than "this is broken"
> is appealing, but it can't (easily) be done via pre-fetch messages while
> still resolving <https://trac.macports.org/ticket/54787>. We need to figure
> out that ports are known_fail before processing their dependencies.
One annoyance that I've encountered is when a fetch dependency needs to be
satisfied even when the distfile archive(s) is/are already present.
Fred Wright
More information about the macports-dev
mailing list