- User Since
- Aug 18 2018, 5:17 PM (92 w, 5 d)
Apr 20 2020
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
Mar 10 2020
Added missing plists
Mar 7 2020
Feb 28 2020
Feb 18 2020
Nov 26 2019
Fix nvidia-driver pkg-plist. Create nvidia-headless-driver-390 (supports oldest generation of Nvidia GPUs used in hybrid graphics configuration).
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
Nov 23 2019
Jul 20 2019
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.
Jul 19 2019
This comment concerns Mesa drivers, and libGL in general, but not much else:
Oct 9 2018
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
Aug 22 2018
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.