Greetings PostgreSQL Maintainers... and Bug Track Community This is a message from a test, trying to improve the environment. And offer some help (and time in the process). Today I was testing something tangent to Postgres and found a very strange behavour - at least to what I would expect. Please allow me to explain... I had done the following steps: 1. installed postgresql17-server 2. installed pyenv 3. used pyenv to install the last version of python 4. using the last version of python's pip to install numpy 5. found then, a problem with numpy depency itself with qt5 So far so good? Well, technically you could ask me... why this is related to PostgreSQL? The problem is.. when I installed the qt5 dependency on my test environment, I found qt5 itself was depending on postgresql16-client (remember.. up to this moment I had postgresql17-server there). THE PROBLEM: There should be no dependency between postgresqlXX-server and any client. At least, that's my first take. Otherwise I can't trust to use postgresqlXX-server on my environment (even for staging without getting concern about other chainned dependencies removing it because they are pointing to older clients). MY QUESTION: How I could help you break this dependency and fix the port? Kind regards, Schmidt, V
Maybe "fix" is not the correct term here, but improve...
(In reply to Vinícius Schmidt from comment #0) I had a quick look at https://cgit.freebsd.org/ports/tree/math/py-numpy/Makefile?id=609fba8daaf6e4be2e627b8c7c7b5005d3c6f822 there isn't a dependency between numpy and postgresql as suggested in point 5, but as you later suggest between qt and postgresql (though I didn't check). None of my systems are current, but could I suggest that you look at /etc/make.conf and modify, or add, DEFAULT_VERSIONS to include pgsql=17? The syntax is: DEFAULT_VERSIONS+= pgsql=17 which might alleviate.?
(In reply to dewayne from comment #2) Following your sugestion and adding that flag does not work. May I ask if you know it was removed? Below an example of the "conflict" which I mentioned before, which creates this problem. Is there a way for 'pkg' to reinstall the packages was removed in a dependency removal? -- ---------------------------------------------------------------- root@vnxs:~ # pkg install postgresql17-server Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. Checking integrity... done (2 conflicting) - postgresql17-client-17.2 conflicts with postgresql16-client-16.6 on /usr/local/bin/clusterdb - postgresql17-client-17.2 conflicts with postgresql16-client-16.6 on /usr/local/bin/clusterdb Checking integrity... done (0 conflicting) The following 6 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: postgresql16-client: 16.6 qt5-sqldrivers-pgsql: 5.15.16p130 qt6: 6.7.3 qt6-base_sqldriver-psql: 6.7.3 New packages to be INSTALLED: postgresql17-client: 17.2 postgresql17-server: 17.2 Number of packages to be removed: 4 Number of packages to be installed: 2 The process will require 54 MiB more space. Proceed with this action? [y/N]:
(In reply to Vinícius Schmidt from comment #3) I'm afraid that I only build from source. I set the options that I suggested to you, in my make.conf before building. If you refer there https://cgit.freebsd.org/ports/tree/Mk/bsd.default-versions.mk you'll see that PGSQL_DEFAULT is 16. You might use my earlier suggestion and rebuild, ie pgsql=17. However if you're using the prepackaged ports system then your expectation of using pg 17 while a python tool has a pg16 dependency, is probably premature. Sorry :-/
Hi! If you need a version of postgresql-server that is not the "default" version for the package build, you will sadly have to use the ports and build manually at this point. Just set DEFAULT_VERSIONS= pgsql=17 in your /etc/make.conf or just install postgresql17-server using cd /usr/ports/databases/postgresql17-server ; make install Make sure you have an up-to-date ports tree. Or you can wait for the bug #283788 to be completed. There are efforts to break the dependency by splitting libpq from client and allowing parallel versions to be installed, but it is not trivial and requires time. Best regards, Palle