[I am resending this message because it was initially rejected since I wasn't subscribed to the mailing list; I apologize if this creates duplicate messages in your inboxes]
>>> Why are we offering this? Selecting this variant would break any port that >>> depends on this port. We should strive not to provide users with ways of >>> shooting themselves in the foot. >>> >> >> Besides this breaking change, it would be good to have this port be >> consistent with findutils and coretuils (and maybe the other GNU ports) >> which install with —program-prefix=g into $prefix/bin and have the non-g >> prefix in $prefix/libexec/gnubin so one can have $prefix/libexec/bin in >> $PATH and get the GNU versions if one wants them. > > It is true that that is how most of the other GNU ports work. However, that > would also break all of the ports that depend on the grep port. It would at > least be more consistent than having this variant, but all the ports that > depend on grep would need modifications to be compatible with your proposed > change. Hi, Sorry, I contributed this change to scratch my own itch of needing to not override the system grep. Honestly, I didn't think about compatibility with other ports so that is a mistake on my part. I see four ways of addressing this problem: - just modify the other ports which deal with the grep port to be compatible with this change - do what Blair suggests and make this port consistent with other GNU ports, as well as fixing compatibility as mentioned by Ryan - add a warning to this variant, saying that it could cause issues - eliminate this change altogether (I really hope this isn't chosen) I think the first or second solution above would be the best. Which other ports reference the grep port anyway? Of course, if anyone has better ideas, feel welcome to chime in. Thanks, - George Plymale II
