> Am 02.10.2020 um 17:02 schrieb Ken Cunningham
> <ken.cunningham.web...@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…
