You are not logged in.
While upgrading (pacman -Syu) I got this error:
error: failed to commit transaction (conflicting files)
ncurses: /usr/share/terminfo/s/st exists in filesystem
ncurses: /usr/share/terminfo/s/st-256color exists in filesystem
Errors occurred, no packages were upgraded
Since on archlinux.org/news there aren't any post about this, I just forced the upgrade. Then ncurses upgraded successfully to version 6.0.3.
Now, however, many commands fail because they expect ncurses 5 to be present:
$ pacman -Syu
/bin/bash: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory
$ bash
bash: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory
This seems like a critical issue. The only workaround I devised is to symlink libncursesw.so (version 6) to libncursesw.so.5 and hope it works. Any ideas?
EDIT: Apparently symlinking did solve the issue, but it's just a temporary workaround. I wonder, why don't bash and pacman (and other programs, like ghc) don't support ncurses 6?
EDIT2: The files that generated the conflict were owned by the package st. As per the wiki, should I submit a bug about that?
Last edited by rubik (2015-09-19 18:56:02)
Offline
It would have been useful to know what package owned those file... however see: https://bbs.archlinux.org/viewtopic.php?id=202562.
You just have to restart bash in order to let it load the new libraries, and you have to rebuild your AUR packages which depend on ncurses.
--edit[1]: Ooops, you already tried to restart bash... are you sure that bash was actually updated? what is the output of
pacman -Qi bash
(if you are able to run that ) ?
--editd[2]: too slow... beated by Raynman.
Last edited by mauritiusdadd (2015-09-19 18:43:17)
Offline
So ncurses was upgraded but bash wasn't? Did you use --force with -Syu or did you decide to forcefully upgrade ncurses separately before continuing with a full upgrade? (And maybe I should drop this link here: https://wiki.archlinux.org/index.php/Pa … 9.22_error)
Do you have pacman aliased to a bash script?
Edit: I guess you read that wiki section already, but just didn't mention anything about ownership before (you could simply reply instead of editing the original post). st is in the AUR, so you can leave a comment there if the conflict still exists. Try running pacman directly before resorting to live iso rescue operations.
Last edited by Raynman (2015-09-19 18:43:30)
Offline
That is unfortunate to have an "exists in the filesystem" error with this particular update. ncurses is a direct or indirect dependency of several important parts of a system (as you have learned). The wiki says to force that particular package which is essentially a partial update. Usually that would work smoothly but this is one of those cases where it doesn't. It is just bad luck and in no way any fault of yours.
A solution is to boot the live iso, mount your filesystems and do pacman -r /path/to/where/you/mounted -Syu. Good luck.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
A solution is to boot the live iso, mount your filesystems and do pacman -r /path/to/where/you/mounted -Syu. Good luck.
If you still have an open shell and cached older packages, then another solution is to extract libncursesw.so.5 from the pacman cache to /usr/lib. Contine the upgrades and then delete it again.
A very dirty solution that might fail and give you all sorts of grief is the one rubik used. In this case it worked, but never rely on symlinking across soname bumps if you can avoid it. If you do that, please remove the symlink again as soon as possible.
EDIT: Apparently symlinking did solve the issue, but it's just a temporary workaround. I wonder, why don't bash and pacman (and other programs, like ghc) don't support ncurses 6?
They don't support both versions at the same time, the packages have to be recompiled. They should have been updated at the same time.
Last edited by progandy (2015-09-19 18:52:28)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
EDIT: Apparently symlinking did solve the issue, but it's just a temporary workaround. I wonder, why don't bash and pacman (and other programs, like ghc) don't support ncurses 6?
Actually latest versions of bash and pacman do support ncurses 6. You must check if your system is actually up to date, and if not do a full system upgrade.
EDIT2: The files that generated the conflict were owned by the package st. As per the wiki, should I submit a bug about that?
That package is in the AUR, so usually you should contact the maintainer of the package... however the package has already been marked as out-of-date and there are already some comment suggesting to remove those files from the packagehttps://aur.archlinux.org/packages/st/.
Offline
Thanks for all the replies! I managed to fix the problem without resorting to the live CD (phew!).
Luckily I'm running zsh, which wasn't affected, so I could run the commands. The problem was that I upgraded all the packages while ignoring ncurses and then forced the ncurses upgrade alone. Bad idea! Because from the first upgrade I had to exclude bash and readline as well, which relied on the new ncurses version. But after forcing the ncurses upgrade, everything stopped working and I couldn't upgrade bash and readline as well.
So I symlinked libncursesw.so.6 to libncursesw.so.5 and I was able to run pacman. @Raynman: yes, pacman was aliased to pacaur, which is a bash script.
I also checked the st package on the AUR. Someone already reported the conflict. The hilarious thing is that I don't even need st anymore, and it was there because I forgot to uninstall it.
Thanks to everyone for the quick support!
Offline
EDIT: Apparently symlinking did solve the issue, but it's just a temporary workaround. I wonder, why don't bash and pacman (and other programs, like ghc) don't support ncurses 6?
They don't support both versions at the same time, the packages have to be recompiled. They should have been updated at the same time.
Yeah, I discovered it the hard way. Next time I'm forcing an update I'll remember to force it on the whole upgrade and not for a single package!
Offline
Next time I'm forcing an update I'll remember to force it on the whole upgrade and not for a single package!
*headdesk* such a good opportunity for learning, completely missed.
Do not randomly force upgrades. Fix the problem, don't just use a bigger hammer.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
rubik wrote:Next time I'm forcing an update I'll remember to force it on the whole upgrade and not for a single package!
*headdesk* such a good opportunity for learning, completely missed.
Do not randomly force upgrades. Fix the problem, don't just use a bigger hammer.
Well usually I check Arch news first. This time, had I forced everything immediately I wouldn't have had any problems. Also, st was a package I forgot about and wasn't even using anymore, so rewriting its files wasn't a problem.
Last edited by rubik (2015-09-19 19:01:02)
Offline
This time, had I forced everything immediately I wouldn't have had any problems.
*head banging to wall*
the chance of winning a lottery where everyone alive on the whole planet gets ONE ticket is bigger then the chance of forcing a pacman -Syu upgrade not giving problems.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I don't understand. Had I removed st and deleted those files, the upgrade would have succeeded. But forcing the upgrade does exactly this: pacman overwrites the conflicting files, which in this case achieves the same result. This is what the wiki suggests. Am I missing something?
Last edited by rubik (2015-09-19 19:11:49)
Offline
Also, st was a package I forgot about and wasn't even using anymore, so rewriting its files wasn't a problem.
But it would have been simpler to remove the st package and do the full upgrade without --force'ing anything. And I'm not sure what pacman is going to do with those files if you decided to remove st now (does it check for conflicts again, or does it assume you deal with conflicts at install time so it can just remove any and all files listed as belonging to st?).
And, again, pacman doesn't link to any libncurses*.so and AFAIK it only needs bash for install scripts, so if you'd just used pacman instead of pacaur, you probably could have upgraded bash, readline and the rest without symlinking.
Last edited by Raynman (2015-09-19 19:23:15)
Offline
I would like to have a large forced update recorded for laughs posterity: screen capture + webcam and free bucket of popcorn for everyone ;-P
Offline
I don't understand. Had I removed st and deleted those files, the upgrade would have succeeded. But forcing the upgrade does exactly this: pacman overwrites the conflicting files, which in this case achieves the same result. This is what the wiki suggests. Am I missing something?
Yup, you are missing the warning in the wiki to be careful with --force, especially when combined with -Syu. That warning is for a good reason as often the result of that is breakage so severe that reinstalling the OS is the best solution.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
rubik wrote:I don't understand. Had I removed st and deleted those files, the upgrade would have succeeded. But forcing the upgrade does exactly this: pacman overwrites the conflicting files, which in this case achieves the same result. This is what the wiki suggests. Am I missing something?
Yup, you are missing the warning in the wiki to be careful with --force, especially when combined with -Syu. That warning is for a good reason as often the result of that is breakage so severe that reinstalling the OS is the best solution.
It might be even possible that everything works fine after you --force your upgrade. Then on the next upgrade (without --force) everything breaks.
Last edited by progandy (2015-09-19 21:35:44)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
It turns out that *after* I looked into the chamber, I saw that it was empty and the round was still elsewhere in the cylinder. So it would have been perfectly safe to play Russian Roulette afterall. Next time I'll just pull the trigger and look like a badass.
Good luck with that.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for the input
I'll definitely be more careful next time!
Offline