Splitting server/client and libraries seems sane to me. Additionally, I'm wondering if there is any reason for keeping contrib separate?

Proposal:

• Move libpq to a separate package (postgresql-libpq?).
• Move client to postgresql-client.
• Keep server as postgresql with dependency on postgresql-client.
• Add postgresql-contrib to the main package.

I am wondering what the upgrade path would be though: you cannot install postgresql-libpq with the old postgres install because of file conflicts, and the new postgres depends on postgres-libpq.

As I still have an update to PostgreSQL 14.2 to do, I'm can pick this up somewhere this week along with the update.

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.

As far as -contrib is concerned, we would need to see whether or not those extensions are used by libpq or the actual postgres binary first. If the library is the actual mechanism for loading them, I could see a case where someone might want -contrib installed for use alongside another client using libpq, without having to install the server itself.

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.

A client and server split could also save space for users that only use the client, but I agree that that it might not be worth the hassle.

These are the installed sizes for a rough split:

19M	postgresql-14.2-33-1-x86_64.eopkg
2,7M	postgresql-client-14.2-33-1-x86_64.eopkg
1,8M	postgresql-contrib-14.2-33-1-x86_64.eopkg
8,5M	postgresql-devel-14.2-33-1-x86_64.eopkg
348K	postgresql-libpq-14.2-33-1-x86_64.eopkg

As far as -contrib is concerned, we would need to see whether or not those extensions are used by libpq or the actual postgres binary first. If the library is the actual mechanism for loading them, I could see a case where someone might want -contrib installed for use alongside another client using libpq, without having to install the server itself.

The server extensions/modules need to be loaded on the server (using CREATE EXTENSION), so I don't think that's the case. There are utility programs that only depend on libpq, but they don't really seem useful without the rest of the server either.

Note that Debian (which are usually all about splitting up packages) has contrib in the main package (see here).

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.

But at the end of the day, I think the main gripe is installing a 20MB package for a 350K library. Let's focus on that and see what changes feel necessary later on.

Agreed! Any idea how to resolve this?

you cannot install postgresql-libpq with the old postgres install because of file conflicts, and the new postgres depends on postgres-libpq.

This is probably a bug to be solved in eopkg. I have a working package.yml for libpq but I can't install libpq if I have postgresql already installed for the reason you told. eopkg should be able to:

1. Detect that we're installing a newer postgresql
2. Detect that we're simultaneously installing a new dependency of postgresql (that is, libpq)
3. Check for file conflicts only in the packages about to be installed, ignoring the current postgresql file list

The eopkg upgrade command will completely ignore file conflicts but the install command does not. For testing locally you can use --ignore-file-conflicts, once the update has been pushed it should no longer be a problem for users upgrading. Issue for pisi: https://github.com/getsolus/package-management/issues/14. Still, we'll need to very careful with how we land it.

No issues with eopkg up. There are some warnings but the update succeeds.

Installing postgresql-libpq, version 14.5, release 37
File conflicts:
/usr/lib64/libpq.so.5 from postgresql gets replaced by postgresql-libpq package
/usr/lib64/libpq.so.5.14 from postgresql gets replaced by postgresql-libpq package

Extracting the files of postgresql-libpq
Installed postgresql-libpq
Installing 2 / 3
Installing postgresql, version 14.5, release 37
Upgrading to new upstream version
Extracting the files of postgresql
Not removing conflicted file : /usr/lib64/libpq.so.5
Not removing conflicted file : /usr/lib64/libpq.so.5.14
Upgraded postgresql

Just did a software update and was surprised to find that I needed to install postgresql. I looked up the reverse dependencies and was again, surprised to find qt6-base. Looks like obs-studio is what added the dependency to qt6-base.

For an OS tailored to home computing, I don't think it makes sense to put postgresql onto users' machines just so they can run OBS Studio. I realize this is not on Solus, but adding my 2c to the thread.