port "cask" -- installing prebuilt binaries

[Lothar Haeger]

> Am 02.10.2020 um 17:02 schrieb Ken Cunningham <ken.cunningham.webuse at gmail.com>:
> 
> So this issue seems still active, but without a decided plan here, people are just starting to PR their favourite approach, which is of course exactly what we are tring to avoid. 

Ken, it's not "people", it's just me who provided an example to revive this discussion after weeks of silence, and I even announced it and asked for feedback in this very thread more than a week ago. 

> The idea of identifying them by a variant suffers from the fact that these are obviously not variants, they are immutable downloaded binaries without a non-prebuilt version. So that is just confusing. 

That's your personal reception, but what you find confusing may be perfectly logical to others, certainly to me. Here's another attempt to explain why I think MacPorts "variants" feature would be a good fit for the purpose:

- each "traditional" variant of a port results in a different binary (compare their checksums...) with possibly slightly different functionality. All traditional variants of a port are still considered the same application/product. This would as well apply to a prebuilt binary redistributed by MacPorts.
- traditional variants may or may not be combined freely, in many cases it's actually either-or. MacPorts supports that via the "conflicts" keyword in variants definitions. "prebuilt" variants would obviously conflict with other variants, nothing unusual here (the current port tree has ~2200 variants out of ~6600 declaring conflicts).
- all ports with a prebuilt variant can easily be identified and even uninstalled with a single command (try the latter with a prefix...)
- prebuilt and compiled-from-source variants can coexist for the same port (both would obviously conflict and could no be combined, though). 
- switching from prebuilt to compiled and back would be just like switching between any other variants.
- variants can be tied to OS versions, so a single port could supply a prebuilt binary for some OS versions and be compiled from source for others - a existing real-world use case
- a "prebuilt" variant can easily be added to existing binary ports (with a prefix, affected ports would have to be renamed with all consequences arising from that)
- an existing "prebuilt" variant can easily be removed if an updated port version finally allows compiling from source. 

> There are very rare ports like ghc where a downloaded binary rebuilds the macports version. In that rare case only, a prebuilt variant sorta makes some sense, but our previous naming scheme where we called it "ghc-bootstrap" was probably more appropriate, TBH.

I generally do not think it's a good idea to mix different kinds of information in a single fields of function. A "name" is a name and not a combination of name and something else. "Something else" should go into the "something else" field or function instead. That's a very low-level design principle that has proven beneficial in almost every context. Whenever it get's ignored, sooner or later funny side effects come up that could've been avoided if a proper solution was implemented instead of some (at the time) seemingly easier workaround.
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'm pretty sure something similar awaits us when a category-or-variant-like piece of information is stored as part of a port name.

Some complications that come to mind:
- to provide the same app prebuilt and compiled-from-source in parallel would require two differently named ports.
- Switching between them would require uninstalling one and installing another.
- Some way to prevent a user installing both of them must be implemented
- unlike other related ports, both yould not eben start with the application name and would not be listed next to each other in alphabetical port listings
- Those two ports may end up with different maintainers and latest availbale versions. Users might have to decide if they rather install the outdated but compiled version or a newer prebuilt port. 
- Which of those two ports should be used as dependency to other ports? Old and compiled or newer but prebuilt?
- If a prebuilt port can be made to compile from source at some point (or a compiled port does not compile anymore but a working prebuilt binary exists) all users will have to uninstall the existing port and reinstall it with a different name (confusing, anyone?). With the variants approach this use case could be handled just like any other update.
- if a prebuilt port is used as a dependency and later can be built from source all dependent ports need to have their dependencies updated. All dependent ports need to be updated together with the was-prebuilt-now-compiled port in order to satisfy all dependencies.

> Chris says put them in a category. Logical, but I don't know if most users would note that when trying to install them, as it is not perhaps obvious enough these are different beasts.
> 
> Really obvious is to tag a small suffix on the name, which nobody could ever miss. Then everyone will know immediately what they are dealing with, including those of us who resolve tickets. That's why I like that idea.

When I read "different beasts" and your concern someone might - heaven forbid - accidentally install a prebuilt binary, I wonder what kind of enemy you see in prebuilt ports and if that's a helpful attitude in this discussion. In my world at least, prebuilt binaries are not bad per-se (actually 99%+ of the binaries on my Mac are prebuilt and most of them not even OSS) and there's no reason to look down on them as lesser citizens in the port tree. 

And I certainly do not think we'll have to rub it into everyones eyes so they "know immediately what they are dealing with". Of course, anyone should have an easy way to find out and maybe even have a way to prevent accidental installation of such "different beasts" (which btw. can be achieved easily with the variants approach, just add "-prebuilt" to variants.conf. Not so easy with a well-known  - or rather "known-bad" - prefix.)

> So lets get some decision, whatever it is, before we have to clean up a big mess as people Bogart ahead with different plans.

Please do not try to discredit "people" by accusing them of "different plans" that only exist in your imagination. I'm all ears to hear about that "big mess" and what exactly might have to be cleaned up at some point, though. Should help identifying and ironing out remaining wrinkles and might even get us back into an factual and constructive discussion along the way…