In D43545#996996, @christos wrote:

This is an (and possible the last) issue this patch has to address. So what happens is, when you unplug the device while jack (and mpv that I noticed) is consuming it, it still keeps the descriptor open and tries to call ioctls on it (see the errors from mpv when you hot-unplug), which means that there are still referenced clones, and as a result pcm_unregister() will block in snd_clone_sleep() until the clone is unreferenced and pcm_unregister() can go ahead to destroy its devfs node. The obvious solution would be to simply ignore the fact that we still have busy clones, and just force-destroy the devfs nodes, but this results in a use-after-free panic because jack will reference freed memory if we free the descriptor and jack tries to use it. This is definitely an application issue (i.e the apps should close the descriptors after failure), but we have to somehow fix this. I am still trying to figure out a solution to this.

Use OPT_IMPLIES for OPTIRUN->VIRTUALGL dependency

Fixed the file paths by uploading a correctly formatted diff this time.

These are addressed by the latest diff.

Simplified the ports.
External source for small scripts is no longer used.
pkg-messages improved.

Thank you for working on this. You are welcome to claim maintainership if you'd like but that it also is not necessary as I do not wish to abandon this project.

The package uses mingw64 and Clang10

Does this pertain to planned work? The patch still shows

DISTVERSION= 9.0.1

etc.

Added missing plists

In D22521#493290, @theron.tarigo_gmail.com wrote:

I let it get lost in switch from 390.x to 440.x patches.
I thought that getting the updated nvidia-headless-driver port to work with the 3xx versions would be more involved because of changed structure, but I just tried it and it works. Thanks!

Fix nvidia-driver pkg-plist. Create nvidia-headless-driver-390 (supports oldest generation of Nvidia GPUs used in hybrid graphics configuration).

In D22521#493197, @monwarez_mailoo.org wrote:

For the pkg-plist of x11/nvidia-driver, there should be this:

So that nvidia-driver-headless could build (package phase) with legacy driver : 390, 340, 304 .

You're absolutely right. I let it get lost in switch from 390.x to 440.x patches.

Use %%EXTENSIONSDIR%%/libglx.so in nvidia-driver/pkg-plist

In D16830#455465, @iwtcex_gmail.com wrote:

In D16830#455463, @theron.tarigo_gmail.com wrote:

How are libGL dependencies handled right now for other ports?

No idea. They likely depend on Mesa and that's it.

I answered my own question here:

After some investigation: /usr/ports/Mk/Uses/gl.mk has hardcoded dependencies on graphics/mesa-libs - ideally this can be fixed, but as part of some other review.

This comment concerns Mesa drivers, and libGL in general, but not much else:

Some of us [FreeBSD users] specifically dislike Debian and their way of doing things. Just so you know. This proposal should be discussed on the appropriate mailing list (or maybe IRC channel, I'm not sure).

It is not any sort of attempt to follow Debian. After a little more research, I see how my proposal could be seen as being similar to Debian's approach to this particular situation, which raises skepticism. I will bring it up on hackers@ once I am more prepared.

Adding so many slave ports seems very messy. This would introduce many architecture-specific slaves to ports which are otherwise not at all architecture-specific in most cases. Fully-functional Wine requires perhaps more libraries than you anticipate: depending on graphics vendor, all of Mesa, and therefore LLVM as well, must be compiled for i386. At least some i386 LibGL is needed for full functionality.^1

Although amd64 and i386 are Tier-1 and freebsd32 compat is a part of base, adding support for lib32 in ports has similarities to porting FreeBSD Ports collection to a new architecture. What is different in this case is that the "new architecture" would be a "slave architecture" to amd64.

Yes, using FLAVORS does not seem quite right. What if one of the dependencies already uses FLAVORS? Regardless of whether this presents a real conflict, FLAVORS is intended for handling varying configurations of ports themselves, not for selecting the manner in which ports are built and installed. The only reason use of FLAVORS is helpful in the present case is that it is an already established way in which one port can generate multiple packages.

In D14721#358258, @dbn wrote:

Thank you all for the useful ideas. I think the first price approach is to create 'lib32-' companion packages for the 32-bit libraries we need. To this end I have created a patch that adds this functionality: https://reviews.freebsd.org/D16830. Luckily the approach is minimally invasive and often involves:

1. Adding lib32 to USES
2. Sometimes replacing uses of ${PREFIX}/lib} with ${LIBDIR}, however lib32 already handles CFLAGS, CPPFLAGS, and CONFIGURE_ARGS (this can be extended as needed)
3. Sometimes adding USE_LDCONFIG=yes

If anyone has some time to convent and test the other library dependencies of Wine that will be a great help :-).

In D14721#357408, @greg_unrelenting.technology wrote:

Hm, so building the "Arch style lib32" packages on-the-fly? That's interesting, but I'm not sure how that would work with official packages. Will poudriere add them to the built package set?

In D14721#348739, @mat wrote:

Side note.

All ports MUST build as a regular user.

We spent a lot of time making sure they all do, DO NOT add new ports that require being root, they will get removed at one point in the very near future.