On 30/8/2025 00:26, Ryan Carsten Schmidt wrote:
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?
I would suggest doing it a little differently: Offer a cliclick port which installs no files but depends on cliclick4 or cliclick5 depending on the OS version.
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.
It also greatly complicates the supporting infrastructure. For example, to correctly show the current versions of ports, ports.macports.org would have to download the PortIndex for every platform, look up every port in every index, record the list of versions found for each port, and also complicate the UI by displaying a table of platforms and port versions.
To correctly check if an archive has been built for a port on a given platform, you have to actually evaluate the Portfile on that platform in case the version in the archive filename changes.
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.
Subports can often make this a bit easier. - Josh
