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