Summary: | Blocking prevents to upgrade postgresql | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | radoslaww |
Component: | [OLD] Unspecified | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | VERIFIED INVALID | ||
Severity: | normal | CC: | 09, cshobe, esigra, gentoo, marti, soletan, weigelt |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
radoslaww
2006-11-11 02:46:54 UTC
(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. *** |