After a postgres upgrade, preserved-rebuild reports: > >>> package: dev-db/postgresql-12.5 > * - /usr/lib64/postgresql-12/lib64/libpq.so.5 > * - /usr/lib64/postgresql-12/lib64/libpq.so.5.12 > * used by /usr/lib64/php7.4/bin/php (dev-lang/php-7.4.11) > * used by /usr/lib64/php7.4/bin/php-cgi (dev-lang/php-7.4.11) > * used by /usr/lib64/php8.0/bin/php (dev-lang/php-8.0.0) > * used by /usr/lib64/php8.0/bin/php-cgi (dev-lang/php-8.0.0) this is an indication that PHP uses an ABI binding against postgres, and should be rebuilt when postgres soname versions change. Presently, the only slot operator in use is "*" > ./php-7.2.33.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.2.34.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.3.21.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.3.22.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.3.23.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.3.24.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.3.25.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.4.10.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.4.11.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.4.12.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.4.13.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-7.4.9.ebuild: postgres? ( dev-db/postgresql:* ) > ./php-8.0.0.ebuild: postgres? ( >=dev-db/postgresql-9.1:* ) Indicating that "any slot is fine" but also not binding to any slot at build time. These should probably read: > dev-db/postgresql:=
The ABI of libpq is notoriously stable. You picked a very unfortunate version of postgresql to investigate this issue with =) If you check the previous library versions, you'll see that "5.12" doesn't have anything to do with the postgresql-12.5 that you installed, but is rather a "MAJOR.MINOR" library versioning scheme: * /usr/lib64/postgresql-10/lib64/libpq.so -> libpq.so.5.10 * /usr/lib64/postgresql-11/lib64/libpq.so -> libpq.so.5.11 * /usr/lib64/postgresql-12/lib64/libpq.so -> libpq.so.5.12 et cetera. The first number (5) changes when the ABI breaks; the second changes whenever some new (backwards-compatible) stuff is added. So long as the "5" doesn't change -- and it rarely does -- any version of libpq is fine for PHP. So, the "dev-db/postgresql:*" is morally correct, just not in practice. And fixing it in practice of course is not so simple... Most programs including PHP are using pg_config to find libpq.so, which just uses the eselected copy, regardless of what the "best version installed as a build-time (DEPEND) dependency" is[0]. So a slot operator that triggers a rebuild when e.g. postgresql-12 is upgraded is incorrect if you had postgresql-11 eselected and if PHP was therefore linked against postgresql-11. The only reason this all mostly works is because the ABI of libpq rarely changes, so nobody cares what major version is installed; whatever is eselected is fine. tl;dr I'm not totally opposed to adding the slot operator, but the rebuilds it's going to cause are not going to deterministically solve your problem. You might get lucky though, and it should work on machines with only one installed version of postgresql. Ultimately it would be nice if these pointless rebuilds could be avoided, but at the moment, revdep-rebuild is going to make you do them anyway, so... If somebody wants to add the operator on the next version bump of PHP, just leave a pointer to this bug for posterity please. [0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-820008.3.3
Ok, I decided to get off my ass and try it. Adding the slot operator doesn't help even on single-postgresql machines, because the "upgrade" is just an installation into a new slot. For example, * Install postgresql-11 * Build PHP against it. * emerge -uDN @world; this pulls in postgresql-12 but leaves postgresql-11 alone * No PHP rebuild happens because postgresql-11 is still there * You depclean 11, and now a rebuild is necessary. So I take it back. This is CANT/WONTFIX unless someone else has a better idea.
This is the first time I've seen PostgreSQL get @preserved-rebuild. (In reply to Michael Orlitzky from comment #2) > Ok, I decided to get off my ass and try it. Adding the slot operator doesn't > help even on single-postgresql machines, because the "upgrade" is just an > installation into a new slot. For example, > > * Install postgresql-11 > * Build PHP against it. > * emerge -uDN @world; this pulls in postgresql-12 but leaves postgresql-11 > alone > * No PHP rebuild happens because postgresql-11 is still there > * You depclean 11, and now a rebuild is necessary. > > So I take it back. This is CANT/WONTFIX unless someone else has a better > idea. The only thing that comes to mind is introducing the postgres.eclass in the PHP ebuild. Then, the POSTGRES_TARGETS will help keep everything in order.
(In reply to Aaron W. Swenson from comment #3) > > The only thing that comes to mind is introducing the postgres.eclass in the > PHP ebuild. Then, the POSTGRES_TARGETS will help keep everything in order. This doesn't solve the subslot rebuild problem per se because it's the new USE flag in dev-lang/php combined with "emerge --changed-use" that triggers a rebuild. It's a portage-only solution instead of the one in the PMS so I don't like it very much =/ Aside from my philosophical objections, it's a lot of extra moving parts (and work for the maintainers) to get back where you started. Running emerge @preserved-rebuild works just find if you're on portage and is actually less invasive than "emerge --changed-use" unless you already pass --changed-use to every emerge command. Preserved-rebuild fixes only actually-broken linkage, whereas --changed-use rebuilds anything whose maintainer is too lazy to revbump.
