When you try to upgrade postgresql from 8.1.4 to 8.1.5 running command: emerge -p postgresql libpq you get the following message: [blocks B ] <=dev-db/postgresql-8.1.4 (is blocking dev-db/libpq-8.1.5) [ebuild U ] dev-db/libpq-8.1.5 [8.1.4] USE="-pg-intdatetime%" [ebuild U ] dev-db/postgresql-8.1.5 [8.1.4] USE="-tcl% -test%" A workaround is to remove postgresql first, with command: emerge --unmerge postgresql Than you can install the newer version with the command: emerge postgresql libpq I don't know if this is postgresql dependency bug or portage bug but I have faced few similiar cases when I had to uninstall packages to make upgrade.
(In reply to comment #0) > A workaround is to remove postgresql first, with command: > I don't know if this is postgresql dependency bug or portage bug but I have > faced few similiar cases when I had to uninstall packages to make upgrade. Not a bug; it's intended (pg_config has been moved to libpq and emerge would fail w/ collisions otherwise).
*** Bug 154842 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Not a bug; it's intended (pg_config has been moved to libpq and emerge would > fail w/ collisions otherwise). Then one could mark libpq-8.1.5 as blocking <=postgresql-8.1.4 and not the other way around - forcing the user to upgrade postgresql first, and then libpq. A mutually exclusive block is not necessary as far as I can tell.
No. Any blocker needs to be mutual.
*** Bug 156002 has been marked as a duplicate of this bug. ***
And what, I need to uninstall postgresql first. It's f***ing impossible. The database is in fact running. I can't afford for such long delay on my pIII600... Especially that pgsql keeps users account info... Damn You!
Use --nodeps to ignore the blocks, worked for me: # emerge --nodeps postgresql libpq I was very annoyed by this behavior as well.
(In reply to comment #7) > Use --nodeps to ignore the blocks, worked for me: > # emerge --nodeps postgresql libpq Except that it will bomb out on FEATURES="collision-protect" - which is the whole point of the blocker being in place... ;)
(In reply to comment #8) > Except that it will bomb out on FEATURES="collision-protect" - which is the > whole point of the blocker being in place... ;) Not as far as I understand it. I'm assuming this description is correct: (From comment #1) > Not a bug; it's intended (pg_config has been moved to libpq and emerge would > fail w/ collisions otherwise). This seems to imply that the pg_config executable (possibly with other files) has moved from the postgresql ebuild to the libpq ebuild. Meaning that if one upgrades postgresql *before*, it will remove the pg_config binary, and when emerging libpq *later*, it will re-add it. I can't see how this could possibly collide -- except that you will not be able to emerge libpq-dependent applications between the two merges. That's why I explicitly ordered the arguments to emerge postgresql first, and libpq next. And also why I proposed a one-way block, although I can see that the window between the two merges might possibly in some rare cases cause breakage.
As already noted above, one-way blocks don't work. Closing this, won't be changed.
(In reply to comment #10) > As already noted above, one-way blocks don't work. Closing this, won't be > changed. They indeed won't work with 'emerge --upgrade' as Portage cannot resolve blocks without user interaction, as is the case with mutual blocks. But I can't see why it wouldn't work when one explicitly issued 'emerge postgresql' (that is, without --upgrade and without libpq) -- if postgresql didn't block <=libpq-8.1.4, the emerge would go through and would let the user upgrade libpq subsequently, without resorting to --nodeps! The postgresql-8.1.5 pkg_postinst could inform the user that they also need to upgrade libpq before any libpq-dependent packages. Fine by me if this bug doesn't get resolved, but "one-way blocks don't work" does not sound like a good justification. Mutual blocks might be necessary in the general case, but an inconsistency with pg_config in the worst case won't kill anyone. I will shut up now. :)
*** Bug 156190 has been marked as a duplicate of this bug. ***
*** Bug 158978 has been marked as a duplicate of this bug. ***
*** Bug 160891 has been marked as a duplicate of this bug. ***
*** Bug 171113 has been marked as a duplicate of this bug. ***
