xbps-install -u xbps may leave system in an unusable state
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- c
- Bereich
- cli, operating-systems
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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)
- Vorherrschende Sprache
- C
- Sterne
- 1.2k
- Forks
- 152
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus void-linux/xbps
-
Typo in configureEvtl. vergeben @Jah-yee hat das vor 3 Tagen übernommen. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
void-linux/xbps#704 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100
void-linux/xbps#475 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
void-linux/xbps#701 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesEvtl. vergeben @outofsyncrs hat das vor 39 Tagen übernommen. Offenbug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
void-linux/xbps#696 ·
Alle Issues in void-linux/xbps
Ähnliche Issues
-
backlog bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
EchoTools/nevr-runtime#653 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
InfiniTimeOrg/InfiniTime#2492 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 80/100
Maintainer antworten meist innerhalb von 1 Tag
-
system: coco
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
FujiNetWIFI/fujinet-config#274 ·
Maintainer antworten meist innerhalb von 1 Tag
-
base-files: 82_config_generate: regenerate /etc/board.json if 0-bytes / truncated after power cutOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
openwrt/openwrt#25940 · 5 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag