https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206194
--- Comment #1 from Kubilay Kocak <ko...@freebsd.org> --- This is interesting. I'll pose some questions (somewhat rhetorically) to help us determine if, how and where this issue might be best addressed. * If compatNx is installed, does that mean the user *always* wants or expects *everything* thing to link against compat libraries? There is a user answer to this question and potentially a ports framework answer, which may be different. * Given the current description of the problem, I would expect *many* ports to be incorrectly linking against or not finding the expected compat libraries, in this case libreadline via USES. Do we know of any other cases that: a) Fail in a similar way (not found, whether they fail to package or not), b) Fail in other ways (linking to different library than expected) * How will readline.mk decide when to depend on compatNx libraries, rather than either existing base ones, or ones from ports, and on what basis and level of granularity. * Does, and if so how is this addressed for other libraries provided in compatNx's that have ports framework and individual port implications? * What is/are the actual 'root' cause(s) here? lang/python27 is implicated only in so far as it doesn't check whether certain C extensions compiled or not, before adding them to the plist. This 'could' be fixed. This is a fairly common type of failure across many ports, whether by virtue of a compile failure, or an OPTION. USES=readline is implicated only in so far as it does not detect the presence of compatNx readline library and provide the necessary *FLAGS to find it. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
