port "cask" -- installing prebuilt binaries
Arno Hautala
arno at alum.wpi.edu
Fri Aug 7 17:21:19 UTC 2020
> On 7 Aug 2020, at 09:04, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
>
> If we use only category to mark as a binary port, what if we have a binary port added (e.g. say lazarus) but then we later find out we can build that port on some systems? Then we want the binary lazarus moved to lazarus-binary, so we can have a real lazarus port that builds from source named lazarus.
> I'm back to using the name to mark binary ports. I believe we will regret not doing that in the end if we don't do it at the start.
I think the naming could indeed be a headache and a port effectively conflicting with itself (binary vs source) is something that should be avoided. I just don’t think the name is the right place for that.
I think I now prefer the variant as the right way to label and deconflict this. Yes, it implies it’s an option, but ports already provide default variants and a portfile could already fail the install if the “prebuilt” variant is manually removed from an install request of a port that only provides a prebuilt option.
The variants.conf file could even list ‘-prebuilt’ to keep these ports from “poisoning” your installation as dependents.
Using the variant solves the naming conflict, is more visible than using a category, and doesn’t overload the port name with metadata.
My only quibble would be that I don’t particularly like “binary” or “prebuilt” for the variant name. Both could be confused with referring to installing from an archive built by the MacPorts build server. Something like “vendor_provided” is lengthy, but maybe clearer as to what it means?
--
arno s hautala /-| arno at alum.wpi.edu
pgp b2c9d448
More information about the macports-dev
mailing list