
Há algum tempo tentei instalar o Steam no meu servidor CentOS 5 e tentei quase tudo que encontrei na Internet e parece que consegui deixar o libstdc++ instalado e não instalado ao mesmo tempo.
O CPanel não está atualizando porque não encontra a versão correta instalada, mas o yum não consegue instalá-la porque já está instalada.
¿Como posso corrigir esta situação e chegar a um estado consistente?
# yum install libstdc++-4.1.2-55.el5
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* contrib: mirror.wiredtree.com
addons | 1.9 kB 00:00
base | 1.1 kB 00:00
centosplus | 1.9 kB 00:00
contrib | 1.9 kB 00:00
extras | 2.1 kB 00:00
updates | 1.9 kB 00:00
wiredtree | 951 B 00:00
Excluding Packages in global exclude list
Finished
Setting up Install Process
Package matching libstdc++-4.1.2-55.el5.i386 already installed. Checking for update.
Nothing to do
# yum remove libstdc++-4.1.2-55.el5
Loaded plugins: fastestmirror
Setting up Remove Process
No Match for argument: libstdc++-4.1.2-55.el5
Loading mirror speeds from cached hostfile
* contrib: mirror.wiredtree.com
addons | 1.9 kB 00:00
base | 1.1 kB 00:00
centosplus | 1.9 kB 00:00
contrib | 1.9 kB 00:00
extras | 2.1 kB 00:00
updates | 1.9 kB 00:00
wiredtree | 951 B 00:00
Excluding Packages in global exclude list
Finished
Package(s) libstdc++-4.1.2-55.el5 available, but not installed.
No Packages marked for removal
# yum reinstall libstdc++-4.1.2-55.el5
Loaded plugins: fastestmirror
Setting up Reinstall Process
Loading mirror speeds from cached hostfile
* contrib: mirror.wiredtree.com
addons | 1.9 kB 00:00
base | 1.1 kB 00:00
centosplus | 1.9 kB 00:00
contrib | 1.9 kB 00:00
extras | 2.1 kB 00:00
updates | 1.9 kB 00:00
wiredtree | 951 B 00:00
Excluding Packages in global exclude list
Finished
No Match for argument: libstdc++-4.1.2-55.el5
Package(s) libstdc++-4.1.2-55.el5 available, but not installed.
Nothing to do
# yum --showduplicates list libstdc++ | expand
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* contrib: mirror.wiredtree.com
Excluding Packages in global exclude list
Finished
Installed Packages
libstdc++.i386 4.3.2-7 installed
Available Packages
libstdc++.i386 4.1.2-55.el5 base
Responder1
Graças a Anthony Geoghegan me apontando a direção certa, consegui encontrar uma solução funcional
rpm -e --justdb --nodeps libstdc++
Isso removerá o pacote do banco de dados sem tocar nos arquivos, então o simples yum install
funcionará.
Responder2
Por curiosidade, primeiro tentaria remover o pacote usando o rpm
comando:
rpm -e libstdc++
No entanto, suspeito que rpm
o banco de dados interno de está corrompido e o comando acima não funcionará, então tentaria reconstruir seu banco de dados usando:
rpm --rebuilddb
Responder3
Isso pode acontecer no pacote x86_64 e multilib. yum remove libstdc++
tenta remover a versão de 64 bits, mas ela não está instalada. Portanto, em tal situação você deve endereçar o pacote com arch. Ou seja:
yum remove libstdc++-4.1.2-55.el5.i386
Responder4
Eu tive uma situação semelhante no meu host.
# yum --showduplicates list coreutils-libs
retornou duas versões do mesmo pacote aparentemente instaladas ao mesmo tempo.
Installed Packages
coreutils-libs.x86_64 8.4-37.el6_7.3 @updates
coreutils-libs.x86_64 8.4-43.el6 installed
Available Packages
coreutils-libs.x86_64 8.4-43.el6 base
Quando eu tentei
# yum remove coreutils-libs
falhou, porque teria que remover outras dependências, incluindohummmem si.
No entanto, depois de várias tentativas e erros, consegui consertar isso. A chave é usar o nome completo do pacote, ou seja, incluindo a versão e o sufixo de lançamento.
O ponto principal é que a remoção de um dos pacotes exigiria a remoção física, mas a remoção do outro apenas removeria o registro rpm do banco de dados e, assim, colocaria o banco de dados em um estado consistente.
No meu caso, pude ver que também tinhacoreutils-8.4-37.el6_7.3pacote instalado, então a versão -37.el6_7.3 era provavelmente a correta (ou seja, a ser preservada).
Quando eu conteihummmpara remover o outro
# yum remove coreutils-libs-8.4-43.el6
tudo funcionou sem nenhum erro e o RPM DB tornou-se consistente novamente.