I'm glad to see that Valve are taking this seriously, but I don't think we are quite there yet. Look at how much of a difference in performance there is just for the client with native on and off. It's night and day. I'd love to finally be in a position where it isn't necessary anymore, but I still have quite a few older games that simply will not run without it. And in the 5 years that we've had it, I've only needed to disable it for one game in a library of over 250 titles.

We probably should find a better long-term solution, but this looks like it fits the immediate need. Thanks for all the testing.

LGTM. Thanks!

For starters, please follow the format for future package requests: https://getsol.us/articles/packaging/request-a-package/en/

So, we've had this discussion more than a few times. PEP 394 was written specifically to address this issue a decade ago. Since then, tools like pyenv and virtualenv have become the gold standard for separating a development environment from the system python. Anyone not using them, should be, and anyone who is already won't be affected.

Saving 2.7M on a client split doesn't really seem worth it to me since it's pretty rare to need the client without the server, even for dev work. 1.8M for contrib was probably to cut down the size of the package originally because of how many things need the library.

I don't really see a need to split client and server into separate packages from eachother. It's not as though installing postgresql automatically enables the server. The bigger issue is that the library is installed on post machines because of its revdeps. Splitting into lib and client/server makes sense to me for saving disk space on user installs. Since most people won't need the server and will use a client like sequeler or qgis that only need the library.

@joebonrichie Can we see the config.log from the failed configure?

We need to have an internal discussion about this one because of bootstrap issues.

Handled over here: R5509:6fb7607c27f4: plocate is a crazy fast alternative to locate/mlocate