In D41802#955897, @rfyu28uyeg_snkmail.com wrote:

Fails to build if security/openssl is installed.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274013

Fails to build if security/openssl is installed.

I think this is good. I'd be inclined to switch BDB to BDB1 for the default. The AGPLv3 licensed BDB should probably not be the default.

I'm not sure we need to mark it as dual licensed if using the BSD licensed db 1.85. The BSD license does not make requirements on derivative works like AGPLv3 does, just on distribution of the lib itself (in binary or source form). The base FreeBSD OS already takes care of those requirements since it is the distributor of db 1.85. I suppose clause 3 is a requirement on derived works (to not use the University's or contributors' names for endorsement of derived works). But other parts of libc are BSD licensed, and we typically don't mark every port that uses libc as dual licensed with the BSD license.

libc/db in base is currently BSD-3-Clause. Advertising clause removed from FreeBSD source tree in 2007.

This update does not build x11-wm/muffin on 12.x.

Updates look good to me. I like '#!/usr/bin/env bash' better (see comments in bug 269584, but I understand the tendency of the project toward hard-coded shebangs in most cases.

In D38429#875293, @vishwin wrote:

Don't get me wrong, I'm not against having bytecode around for CPython execution, because performance benefits do exist amongst other things. But they can't needlessly pollute the filesystem in an inconsistent and non-repeatable manner.

Yes, this looks good - I have been using USE_GCC=11+ for emacs & NATIVECOMP for a few months now with success. Sorry I forgot to submit the change for review - and thanks for picking it up. -- John

Another option is to close stdin for the command feeding the pipe to grep (e.g., readelf):

I added a patch based on Joseph's patch here in the PR. It only addresses the EMACS circular dependency issue and doesn't include the update to 3.8. I attached the patch there instead of here to avoid confusion. Maybe there's a good way to present an alternate patchset on the phab page, but I don't know how.

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237972 to fix some cases of OPENSSL_LDFLAGS (with proposed fix for Uses/ssl.mk).

Abandoning this change (probably not applicable to enough ports).

See recent comments in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 for stage-qa problems with this change.

In D10554#219970, @mat wrote:

And if all this is only to fix the couple of ports that extract their distfiles directly in STAGEDIR during install, I think those should be fixed instead, not the framework.

In D10554#219965, @mat wrote:

This makes the shebangfix.mk code a lot more complicated.

In D10554#219966, @mat wrote:

As a side note, if you need to "patch" shebangs after the build process has run, you are doing it wrong, you should provide the correct path, or patch the build process so that the correct shebangs are generated.

Added updates to three ports affected by the prospective changes to shebangfix.mk

Installing under ${PREFIX} (typically LOCALBASE) is generally preferred. The most common things installed outside of PREFIX/LOCALBASE are things under /var. Many kernel module ports install to /boot/modules.

In D10398#215440, @cem wrote:

Does that mean the port would need a runtime dependency on gdb for the /usr/local/share/gdb directory? If not, seems like a good idea to me.

I've seen other -gdb.py files installed to share/gdb/auto-load (such as /usr/local/share/gdb/auto-load/usr/local/lib/libglib-2.0.so.0.5000.2-gdb.py from the devel/glib20 port). Should the python -gdb.py file be installed there, too?

What about packages that install libraries somewhere other than ${PREFIX}/lib? For example devel/llvmXY, installs to ${PREFIX}/llvmXY/lib and adds that path to a file in the ldconfig/ directory.

I was trying to follow the discussion at llvm bug 30848, but the thread ran cold - there are still some unanswered investigation questions.

That's ugly (my id which is my anti-spam email address). I wonder if phabricator has a setting to override that -- John Hein

Looks good. Thanks, Jan.