On Fri, Aug 29, 2025 at 09:26:26AM -0500, Ryan Carsten Schmidt <[email protected]> wrote:
> Should we continue to allow changing the port version based on OS > version? Currently we do this in several ports e.g. to offer the last > compatible version to old OS versions. Josh brought up in a ticket > that we should consider not doing that, and instead create separate > versioned ports. I thought we should discuss because there are pros > and cons to each approach and currently we have a mix of strategies. > > For example a user who wants cliclick just installs the port. It > picks the right version for the OS version. This is simple for the > user. The alternative is that a user of an old OS would have to know > to install a hypothetical cliclick4 instead. And the situation becomes > complicated if the criteria change. For example, if I later figure out > a way to offer version 5 to some older OS versions, how does the user > who installed cliclick4 learn of that? > > But such ports that mutate to fit the environment are more complex to > write and maintain. And we have to remember that we can only change > the version (and any other property that goes into the portindex) > based on the segmentation of our server-side portindexes. We maintain > separate indexes for each OS version/arch combination so we can change > a port version based on OS version or arch but not based on other > criteria like Xcode version. > > Sometimes the single mutating port strategy doesn't work so well. The > go port is an example. Many go modules fail to build on older systems > because they require a newer go than the latest one that works on the > older system. But this wouldn't be solved by switching to multiple > versioned go ports. Each go module port would still need to know > its minimum go version which it currently doesn't. Or, depending on > how common it is for modules to require newer go versions, we could > dispense with the idea of go supporting old systems entirely. > > The separate versioned ports strategy also doesn't always work well > because it takes continual effort to keep them in sync. The postgresql > ports for example are all a little different from one another because > at various times a fix or a reformat only got applied to one of them > but not the others. I think it would be unfortunate if every user of old systems was required to know which is the latest working version of each port for their operating system. If this is unavoidable, it would be good to document clearly a matrix of working os/port compatibilities, but that sounds unwieldy. I know I have to explicitly exclude updating MacVim on 10.6 and I keep having to add more ports to the list that can't be updated. It's manageable, but it would be great if macports just knew what did and didn't work for different operating systems. But of course, that depends on bug reports which may or may not ever get resolved, so it's very tricky. cheers, raf
