I'm a sysadmin for a university computer science department and we're going to roll-out Gentoo in our labs. I *don't* want PostgreSQL installed on all machines, but *do* want the client available on all machines. Basically, I want the Perl libs, the Python libs, the Java libs, the C libs, and the psql program, but no server. There should be an ebuild for this or a "noserver" USE flag or something. As is, we'll probably leave it off for now and then hack the existing ebuild to add the client functionality only. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Install client and server always. Expected Results: Install client only when desired.
Oops...expected should read "server only when desired."
I've thought it. Actually, I've made ebuilds for resolving this problem in my PC. But I don't know how we should do as gentoo way. See bug 12499.
*** Bug 67048 has been marked as a duplicate of this bug. ***
I've added expermental ebuilds called libpq-{3.2,4.0}.ebuild to portage tree as package.masked. It allows you to install only client library to your box. I've also added these ebuilds against libpq package, which are also package.masked. =dev-db/pgpool-2.5.2-r1 =dev-db/pgadmin3-1.2.1-r1 =dev-db/pgeasy-3.0.4 =dev-db/pgst-1.3 (these postgresql ebuilds depend on libpq package) =dev-db/postgresql-8.0.1-r4 =dev-db/postgresql-8.0.2-r2 Can anyone test it?
*** Bug 91350 has been marked as a duplicate of this bug. ***
i emerged the packages: pgpool: compiles fine but i don't know how to use/test it ;) pgadmin3: works fine pgeasy: compiles fine but again don't know how to test it pgst: compiles fine but needs some improvements which brings us back to the original problem: there is still no ebuild for the postgresql-client (aka psql - not the emacs thing which is already in portage) and pgst needs a dependency on the postgresql-client...
I'm not sure if this should be here, or is a new enhancement request, but since this is where libpq originated from... Now that libpq is a separate ebuild, many, if not all, packages that support the "postgres" use flag should depend on libpq, not postgresql directly.
Exactly. And we're working on it. But we would like to stable the latest version bumps (7.3.16, 7.4.14, 8.0.9, 8.1.5) first. Starting with this versions, pg_config will not longer be installed by postgresql, but by libpq, which is needed by many packages to compile. After that we will start to change the dependencies in all the ebuilds :)
An issue with the breakout of libpq is the conflict across version numbers. For example, I'd like to upgrade from 8.0.9 to 8.1.5. The problem is in order to compile postgresql-8.1.5, I now have to upgrade libpq to 8.1.5, which causes a conflict with the installed postgresql-8.0.9. Because the releases are incompatible, I need to dump the database first and take it offline while waiting for both libpq and postgres 8.1.5 compile (a significant amount of time). If someone has uninstalled postgresql-8.0.9 in order to upgrade to libpq-8.1.5, they now have a surprise when postgresql-8.1.5 fails to build because the old data is there and they can't dump it because postgresql-8.0.9's pg_dump is gone. All this is the long way of saying, there should be a way if performing these upgrades with less downtime. When there was just postgresql, I was able to build the binary package (or use ebuild postgresql... install) while the existing database was running, which meant only being down for the copying of files and data import. Is there some reason that libpq-8.1.5 needs to conflict with postgresql-8.0.9? If it didn't, then I could compile postgresql-8.1.5 as a binary package again. Could SLOTting take care of this?
Please read the upstream documentation. You can't upgrade from one major version to the next one. SLOTTING could take care of this in the way that you can install both 8.0.9 and 8.1.5 side-a-side which lessens the downtime massively :) Some notes about this: http://overlays.gentoo.org/proj/postgresql/wiki
Solved with the new split into dev-db/postgresql-{base,server} Cheers.
