verify shlib errors on partial upgrade bypassed by multilib
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 45/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- c
- Domaine
- cli, operating-systems
Piste de recherche
Reproduce the issue using the linked testpkgs.zip and the xbps-src/xi command sequence in the report. Start by tracing the shlib checks used during xi -u and how installed 32-bit and 64-bit packages are recorded. Done means the reported partial-upgrade scenario warns about the broken 64-bit application instead of allowing the 32-bit package to bypass the check.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
When performing shlib checks before upgrading, libraries provided by 32bit packages are treated the same as libraries provided by 64bit packages. This can result in system breakage on partial upgrades without warning as noticed on the r/voidlinux subreddit: https://www.reddit.com/r/voidlinux/comments/18r0swm/psa_libxcrypt_updates/
I verified this behavior using the following:
- Download testpkgs.zip
- Run
./setup.sh - In the cloned void-packages repo run:
./xbps-src binary-bootstrap
./xbps-src -m masterdir-i686 binary-bootstrap i686
./xbps-src pkg libhelloworld
./xbps-src -m masterdir-i686 pkg libhelloworld
./xbps-src pkg test1
xi test1
- You can run
test1and it will outputhello world 7as expected. - After that, modify the libhelloworld package to not install libhelloworld.so.1 and build it as
version=2(do not build the 32bit package with this change). - When doing
xi -u, you will receive a shlibs error as expected.test1-1_1: broken, unresolvable shlib 'libhelloworld.so.1' - Run
xi libhelloworld-32bit - Now run
xi -uagain, you will not receive any warnings and the upgrade will proceed as normal. - Confirm the breakage of
test1as running it now outputstest1: error while loading shared libraries: libhelloworld.so.1: cannot open shared object file: No such file or directory
Ideally, xbps should be able to detect that the libraries provided by 32bit packages are not applicable to 64bit applications and visa-versa.
- Langage dominant
- C
- Étoiles
- 1.2k
- Forks
- 156
- Merge moyen
- 1 h 39 min
- PR mergées (30 j)
- 1
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de void-linux/xbps
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 68/100
void-linux/xbps#475 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
void-linux/xbps#701 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesPeut-être pris @naevui l’a pris il y a 60 jours. Ouvertebug
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
void-linux/xbps#696 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 52/100
void-linux/xbps#695 · 7 commentaires ·
Toutes les issues de void-linux/xbps
Issues similaires
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 75/100
Les mainteneurs répondent en général sous 10 jours
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 1-3 heures Accessibilité débutants 83/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
sk3llo/ffmpeg_kit_flutter#176 ·
-
Synth suite fails unless run from the repo root: signal_flow's default machine path is cwd-relativeOuvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 80/100
Nimblesite/osprey#370 ·
Les mainteneurs répondent en général sous 1 jour