xbps-install -u xbps may leave system in an unusable state
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- c
- Área
- cli, operating-systems
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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)
- Lenguaje dominante
- C
- Estrellas
- 1.2k
- Forks
- 152
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de void-linux/xbps
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
void-linux/xbps#475 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
void-linux/xbps#701 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesPosiblemente ocupada @outofsyncrs la tomó hace 35 días. Abiertobug
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
void-linux/xbps#696 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
void-linux/xbps#695 · 7 comentarios ·
Todos los issues de void-linux/xbps
Issues similares
-
docs: AGENTS.md has no rule against running deploy scripts into the owner's game installPosiblemente ocupada @thesprockee la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
EchoTools/nevr-runtime#524 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
-
type: feature
Dificultad 1/5 Menos de una hora Aptitud para principiantes 77/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
FujiNetWIFI/fujinet-firmware#1932 ·
Los mantenedores suelen responder en 1 día