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