> On 7 Aug 2020, at 09:04, Ken Cunningham <[email protected]> > 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 /-| [email protected] pgp b2c9d448
