xbps-install -u xbps may leave system in an unusable state
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
- Tipo de issue
- Funcionalidade
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Stack de tecnologia
- c
- Domínio
- cli, operating-systems
Direção de pesquisa
Start in lib/transaction_ops.c around lines 276-285 and trace how xbps-install -u xbps handles missing dependencies and shlibs. Reproduce the glibc 2.38/libcrypt.so.1 scenario, then define and validate a safer self-upgrade path that does not leave core dependents such as PAM unusable.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
When updating through xbps, if the repositories have an update for xbps available, then the only install/update action that may be performed is xbps-install -u xbps.
Since this may sometimes result in a situation where xbps may be unable to be updated since one of its dependencies may break their dependents, the decision was made to have xbps-install -u xbps ignore all missing dependency and missing shlibs errors:
https://github.com/void-linux/xbps/blob/master/lib/transaction_ops.c#L276-L285
This is problematic since with glibc 2.38, libcrypt.so.1 was dropped. In order to upgrade xbps, glibc must be updated, however, the glibc upgrade may break glibc dependents, which gets ignored.
The comment in the transaction_ops.c file suggests that you can just make sure to do xbps-install -Su afterwards and the problem will be resolved, however, if something like PAM gets broken, then now you now are going to have a real hard time logging in or changing user (sudo, for example, won't work anymore).
My question is, is this really the best way to handle this or is there a more intelligent way to handle xbps self upgrades.
(I know it is too late to fix this for the old ISOs but if we can fix this for the future, then that would be nice)
- Linguagem predominante
- C
- Estrelas
- 1.2k
- Forks
- 156
- Merge médio
- 1h 39min
- PRs com merge (30d)
- 1
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de void-linux/xbps
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 68/100
void-linux/xbps#475 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
void-linux/xbps#701 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesTalvez já em andamento @naevui assumiu há 58 dias. Abertabug
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
void-linux/xbps#696 ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 52/100
void-linux/xbps#695 · 7 comentários ·
Todas as issues de void-linux/xbps
Issues semelhantes
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 83/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 85/100
Mantenedores costumam responder em até 9 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
containers/bubblewrap#826 ·
Mantenedores costumam responder em até 1 dia
-
Vulkan: create_device reads the device extension list after freeing it (random crash at start)Aberta
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 62/100
Revivedx/SavageWindRecomp#488 ·
Mantenedores costumam responder em até 1 dia
-
needs-device
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100