Hi all, i have proposed a MR[1] for the PostgreSQL package.
The main reason for this MR is they way PostgreSQL handles upgrades. The best practice is to use the `pg_upgrade` utility. But this tool needs both ( meaning "old" and "new" ) major versions installed. currently, the user will have to dump and import the complete database, to do an upgrade. Another reason for this is, that as a PostgreSQL DBA and developer, i need to test certain things against different versions of the database. Other people may have the same needs. During the development process for the slotting of dev-db/postgresql, there was some discussion how to handle the PostgreSQL client binaries. Best practice for PostgreSQL is, to use always the latest binaries. This could be done with alternatives, but there are some caveats with this: - handling alternatives is a pain in the ass. - removing the highest slot of the package (because it is unused, does not work with the used software, ...) may break things. -- Depending on the "best version" may be a solution, but it adds unneeded dependencies. libpq is downwards compatible, meaning that nevers versions of the library will work with programs linked against an older version. So, there is not always a need to rebuild, just because the "best slot during installation" was removed. - the biggest issue is `pg_config`. As pg_config is used to find the correct library paths it would always point to the slotted install directory, making the dependencies for clients even worse. And the same tool is used for server- side extensions, which require to always be build against the correct server version. Fiddling with pg_config would be nasty and could break some things very hard. So, i decided to split the package in client ( unslotted ) and a slotted server package. I used the instruction from the PostgreSQL Docs[2] for the client only installation as a base for potsgresql-client. [1] https://gitlab.exherbo.org/exherbo/arbor/merge_requests/143 [2] https://www.postgresql.org/docs/10/static/install-procedure.html So long, Thomas _______________________________________________ Exherbo-dev mailing list Exherbo-dev@lists.exherbo.org http://lists.exherbo.org/mailman/listinfo/exherbo-dev
