| Summary: | app-eselect/eselect-postgresql Unable to create link! If postgres has been previously installed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | FireFish5000 <firefish6000> |
| Component: | Current packages | Assignee: | PgSQL Bugs <pgsql-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Colored stdin, stdout, and stderr of the command in Steps to reproduce | ||
|
Description
FireFish5000
2017-08-04 17:14:48 UTC
Which version do you have? (postgresql-config version) it happens pretty much with any version of postgresql, which quite clearly described by reporter. easy steps to reproduce: 1. emerge postgresql:9.4 2. emerge -auDN @world will give you a newer postgresql:10 slot 3 eselect postgresql set 10 Also, due to fact symlinks are broken, postgresql cannot be cleanly uninstalled from system leaving orphans. Created attachment 488082 [details]
Colored stdin, stdout, and stderr of the command in Steps to reproduce
Results as run on my machine.
Yes, it happens when trying to upgrade between any two versions of postgres. The actual issue is a bit more complex than I initially believed, however, I believe the issue will affect the majority of first-time gentoo postgres upgrades. I initially ran into this error after upgrading from PostgreSQL 9.6 to PostgreSQL 10. I had installed 9.6 via 'emerge postgresql'. The update was done automatically by 'emerge -NvDu @world' and the problem occurred when I removed the old version with 'emerge --depclean'. [Who this affects]: This only seems to affect people UPGRADING postgresql, that are uninstalling the older, but still active (as far as eselect is concerned) version. I believe this will be the majority of the users, or at least most novice users who installed postgres without specifying a slot or version. Future upgrades will install a newer postgres version in a new slot, and then depclean will remove the old version, which will initiate the problem if the user didn't already manually change to the new version. [Who is NOT affected] Surprisingly, despite the similar scenario, the following people do NOT seem to be affected: a) Those re-installing the active of postgres, b) Those uninstalling the active and only version of postgres (Future installs will succeed). c) Downgrades, those uninstalling the newest and active version of postgres, but with an older version still installed (which will be automatically set to active). d) Anyone who switches the active version to the new one before uninstalling the old version. [Steps to Reproduce]: 1) Install any 2 versions of postgres. 2) Set the lowest version to active. 2) Uninstall the active postgres version. eg. emerge -1 postgresql:9.6 postgresql:10 eselect postgresql set 9.6 emerge --unmerge postgresql:9.6 # eselect postgres update will fail during unmerge. Confirm its broken eselect postgresql list eselect postgresql set 10 [Current problem summery]: postgresql ebuild's pkg_postrm calls 'eselect postgresql update' eselect-postgresql's do_update calls do_set which calls do_unset. do_unset fails to remove some links for some reason. [My thoughts]: Changing all 'ln -s' to 'ln -nsf' does work around the problem, at least on the surface. The real problem seems to be related to the 'do_unset' and/or 'do_update' functions. I have not looked too far into them sense changing to 'ln -nsf' fixed my problem, and will likely ensure all upgrades work. However, there is still a risk of old links not being removed or overwritten. eg. if the new version of postgres no longer contains/uses a file, and do_unset failed to remove a link to it, then the link will be left untouched by do_set. Thus leaving a probably harmless broken link. Even if/when we fix whatever the actual error is, I still believe the 'ln -nsf' should be added/left since it reduces the risk of the do_set function failing mid-operation, and thus leaving postgres links in chaos pointing to two separate versions. I asked for the version of the eselect module, not the version of PostgreSQL. $ postgresql-config version postgresql.eselect 2.2 eselect 1.4.8 And, from what's been described, this is fixed with version 2.2. *** This bug has been marked as a duplicate of bug 625368 *** |
