Summary: | dev-db/postgresql multiple package instances single slot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | John (EBo) David <ebo> |
Component: | New packages | Assignee: | PgSQL Bugs <pgsql-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | david.w.noon, ebo, patrick |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
John (EBo) David
2009-05-29 05:48:51 UTC
This is confusing... libpq is slotted, but it blocks entire ranges of postgresql versions. Meanwhile, postgresql depends on the same version of libpq as itself, which means that postgresql and libpq must be stabilized in lock-step, or it will create problems like this... That is if libpq really must be slotted, and postgresql is installed, portage must somehow magically resolve not to upgrade libpq. If the slotting isn't truly necessary, however, the blocking dependency can just be removed, since postgres can only have one version of libpq anyway. (In reply to comment #1) > This is confusing... libpq is slotted, but it blocks entire ranges of > postgresql versions. Meanwhile, postgresql depends on the same version of libpq > as itself, which means that postgresql and libpq must be stabilized in > lock-step, or it will create problems like this... Since virtual/postgresql-base has libpq as a dependency with versions matching, they must be upgraded in concert. Moreover, it would simplify matters if the slotting of libpq were identical to that of the other PostgreSQL packages. As things stand, stable PostgreSQl packages are in slots 8.0 and 8.1, while stable libq is in slot 4 (even though it is version 8.0.15). Has there been any movement on this issue? I ask because it is holding up the upgrade to slotted PostgreSQL. sorry for the delayed reply -- seems I forgot to CC myself on this one... I just removed the package.keywords hack around this and find that virtual/postgresql-{base,server}-8.1 are now marked stable for 8.1. I am not sure what this means for other architectures, but it now works for me out of the box. I also have not tested it with 8.2 or 8.3, but it looks like it is now resolved. Marking as fixed. (In reply to comment #4) > I just removed the package.keywords hack around this and find that > virtual/postgresql-{base,server}-8.1 are now marked stable for 8.1. I am not > sure what this means for other architectures, but it now works for me out of > the box. I also have not tested it with 8.2 or 8.3, but it looks like it is > now resolved. It certainly is *not* fixed. It is still not possible to have both the 8.0 and 8.1 versions of libpq installed cocurrently. As a result, I cannot have both 8.0 and 8.1 versions of the servers on my network and access both from any machine. I re-state what I said above: the slotting of libpq *must* be in concert with the slotting of postgresql-server. As things stand, you can install 8.1 on its own, without 8.0, and it will work. But having multiple slotted releases working is still not possible. Should we reopen this bug then? My original issue has been resolved, but I see that the libpq issues has not. (In reply to comment #6) > Should we reopen this bug then? My original issue has been resolved, but I see > that the libpq issues has not. Given that the root problem remains unfixed, I think reopening would be a good idea. bug reopened. Sorry for the consternation. I really thought the issue was resolved. Happy hunting. Short version, as soon as postgresql-base postgresql-server are stable libpq and postgresql will be masked. And this issue will resolve itself then :) Sorry for the mess, I have no idea how and why this confusing keywording happened. Not a big problem for me. Just let me know if you need me to follow up on anything or remark the bug as resolved/fixed/etc. EBo -- libpq and dev-db/postgresql are history. Bug is now impossible :) Closing. |