Lothar, I agree with most of your reasoning for why a variant is a reasonable choice for indicating a prebuilt binary. I am less concerned with how to indicate prebuilt status than I am with whether we should do it at all.
For ports that are not available any way other than prebuilt, I'm not sure what's gained by adding a default variant that can't be turned off. It tells the user it's a prebuilt binary, but will they really care? As for the scenario where we want to compile on some OS versions and offer a prebuilt binary on others, do we have specific examples of ports where that would be used? I forget but I would hope this situation arises very infrequently. I suppose osxfuse might be one, where we can compile our own on < 10.11 but have to use a prebuilt binary on 10.11 and later because it is a kernel extension and Apple requires that those be signed by a real developer on 10.11 and later. But even then: why not just make the port compile on < 10.11 and use a prebuilt binary on >= 10.11, which is kind of what the port should be doing now except that it has bugs? Why does that need to be communicated to (or selectable by) the user via a variant or any other means? To your other point: On Oct 2, 2020, at 17:42, Lothar Haeger wrote: > MacPorts already uses port names to store non-naming information in one > common use case: when multiple versions of a port should be maintained in > parallel. Think of perl: p5, p5.26, p5.28, p5.30 and the gazillions of > derived port variants. Basically every single perl extension exists in > multiple versions to make all versions of perl happy. Same for python and > some others. > Instead of creating separate copies of perl for each version, it would've > probably been smarter to fix the limitation in MacPorts that made this > workaround necessary, i.e. its inability to maintain and install all but the > latest version of a port. RPM can do it, DEB can do it, MSI can do it, > nothing unusual in the grand scheme of package managers in general to be able > to choose a specific version to install. Just MacPorts did not implement it > yet and when the necessity arose a seemingly simple workaround was chosen > instead of solving the underlying problem. I have no familiarity with rpm, deb, msi, or other package managers so I cannot say whether or how they allow the user to select which version of a package to install. As for MacPorts, it's not that we haven't implemented it because we're lazy. It's because, besides being an unimaginably large amount of work in rearranging our code to do it, I have absolutely no idea how it would be accomplished without providing the user with unlimited opportunities to create broken combinations of port versions, which would generate an unlimited number of bug reports that we would then need to respond to, and my goal in MacPorts is to reduce, not increase, the likelihood that users would find something broken or need to contact us to help troubleshoot it. If you have an idea for how it could be done without such problems arising, please open a new topic and describe it and we can talk through a few scenarios and see if it works. I'm speaking of the user being able to specify an arbitrary version. If you're instead thinking that the port maintainer would specify a list of valid versions or something, that might be more feasible, but still not without some of the above problems. I consider it a feature, not a bug, that we offer multiple ports for different versions of perl, php, python, ruby, gcc, clang. It enables the user to install multiple versions of those languages that can all be active and available at the same time. If the user has one script that works with python 3.8 and another that requires python 3.6, no problem. If they have one web site that works with php 7.4 and another that needs php 7.2, no problem. If we only had a single python or php port that only let the user choose a single version to install at a time, that would not be possible.
