Re: port "cask" -- installing prebuilt binaries
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.
Re: port "cask" -- installing prebuilt binaries
> Am 02.10.2020 um 17:02 schrieb Ken Cunningham > : > > 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
Re: port "cask" -- installing prebuilt binaries
> On Oct 2, 2020, at 8:02 AM, Ken Cunningham > wrote: > > 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. Also, it it is decided to go ahead with the idea of identifying these using only a category, I’m not certain how to handle the situation where the port can build on newer systems, but needs a prebuilt binary on older systems, and that line might move over time as newer systems become older and need the binary instead of building. K
Re: port "cask" -- installing prebuilt binaries
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. 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. 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. 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. So lets get some decision, whatever it is, before we have to clean up a big mess as people Bogart ahead with different plans. Ken
