Hi Ryan,
thanks for bringing up this topic, it is a complexity and me, as a user
of old and even obsolete system, am interested in this.
I add a couple of variables to your reasoning.
First, overlays and local repositories. I know that officialli it is
more or less "discouraged", but I do it, Ken do it and I think more or
less everybody with really old stuff (e.g. 10.5/10.6) does it to a
certain degree: it is needed for testing and unblocking.
Of course, ideally things go "upstream".
With local repositoris, the single version is best: it is easy to know
which port to "locally" override. Typical scenarios include
1. fixing a dependent library to an older version and see if everything
"upwards" work. (had to do it regularly with harfbuzz & friends, for
example)
2. locally allowing a not-supported port to compile: e.g. I rise the
minimum version of MacOS required and apply patches to force it to work.
In a multi-version environment this sounds more complicated, I would
need to override everytime a different port?
Would these different ports, if they are a dependency, "provide" the
same functionality. Suppose "libclicklick"... both libclickclick2 and
libclick3 provide a dependency for clickclick.
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?
From a user point of view, a single clickclik port is for sure the
best. A newer version is gotten to work with a patch or by a fix of a
dependency (suppose an improvement in legacy-support): just a raise is
needed and all users will get it via an update.
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-
I think we have a similar issue with rust.
I throw in another issue: variants. A port might have different
requirements there.
E.g. "+x11" might have a lower requirement than "+quartz". This wides
permutations and I don't even know if it is handled at all.
Riccardo
