Postgis installs files only for the currently-eselected version of postgresql. For example if pg9.3 was the default when you installed postgis, you cannot (easily ?) install postgis on one of your pg9.2 databases. The workaround is to eselect the desired pg slot, reemerge postgis, and install postgis into the desired dbs. It is easy but tedious, especially if (like me) you support multiple pg versions and regularly create test dbs. Reproducible: Always Expected Results: Being able to select which pg slots to install postgis for would be cool but probably too much work for what it's worth. It should be simpler to install postgis for all currently-installed postgres slots.
There is an eclass in the works that addresses this.
Any updates on this?
I don't know about the upcoming eclass, but I ran into the problem again for the pg_repack extension, and used a solution you can see in bug #517006. My solution is simple and worksforme(tm), but it does all the work (configuring, building, installing) in src_install, which is a dirty trick. If there's an eclass that does a cleaner job I'd be happy to use it, otherwise I vote to use this technique for all PG extensions.
Actually, there's also the option of sloting all PG extensions the same way PG itself is sloted. It's a little bit more work for the users and for the ebuild maintainers, but it's a straightforward solution with no strange ebuild nor dirty trick involved.
Sorry this has taken so long to get a Round Tuit. It's being worked on now that this is a renewed obsession.
Any news on the multislot problem? I would gladly help testing and a little bit developing (I don't know ebuild well, but I'll try) One problem I hit was, that pg_upgrade refuses to work when postgis is not installed for all postgresql slots.
(In reply to Benjamin Börngen-Schmidt from comment #6) > Any news on the multislot problem? I would gladly help testing and a little > bit developing (I don't know ebuild well, but I'll try) > > One problem I hit was, that pg_upgrade refuses to work when postgis is not > installed for all postgresql slots. I switched my focus to unifying the PostgreSQL ebuilds. The were some problems that were best solved by having unified ebuilds rather than trying to work with the split ebuilds. Now that we have unified the PostgreSQL ebuilds, it'll be quite easy to continue work and testing on the postgres{,-multi}.eclass.
I've finally gotten around to something that looks like it's working. https://github.com/titanofold/titanofold-gentoo-x86/tree/pgsql-eclass Complete with a working-for-me PostGIS 2.2.1 ebuild.
commit 2c4b507dc7ed76eab9e85a6ce399a6cd6b4c6d34 Author: Aaron W. Swenson <titanofold@gentoo.org> Date: Sun Jul 9 22:21:29 2017 -0400 dev-db/postgis: Use postgres-multi.eclass Now installs to all selected slots. Bug: 496894 Package-Manager: Portage-2.3.6, Repoman-2.3.1
