sqlite is the deferred item this port had written down long ago -- "libtcl8.6
versus our tcl 9.0" -- arriving as a missing directory:
mv: cannot stat '<pkgdir>/usr/lib/tcl8.6/sqlite*': No such file or directory
The version is read from the tree rather than written in, because the tcl package
decides it and hardcoding 9.0 puts the same trap back one release later.
The first attempt guarded with a blanket `grep tcl8.6` and condemned correct
code: the existing section of that hook names tcl8.6 on purpose, because it is
about the HOST's tcl. It also substituted $_tcldir into that older section,
before the variable was defined. The guard caught both.
util-linux is the seventh package to fail on a path at the end of package() after
a compile that worked. libpsl's error names its own fix.
--- FR ---
sqlite est l'élément différé que ce portage avait noté depuis longtemps —
« libtcl8.6 contre notre tcl 9.0 » — arrivant sous la forme d'un répertoire
absent :
mv: cannot stat '<pkgdir>/usr/lib/tcl8.6/sqlite*': No such file or directory
La version est lue dans l'arbre plutôt qu'écrite en dur, parce que c'est le
paquet tcl qui la décide et qu'inscrire 9.0 remettrait le même piège une version
plus tard.
La première tentative gardait par un `grep tcl8.6` global et condamnait du code
juste : la section existante de ce hook nomme tcl8.6 exprès, car elle traite du
tcl de l'HÔTE. Elle avait aussi injecté $_tcldir dans cette section antérieure,
avant que la variable soit définie. Le garde a attrapé les deux.
util-linux est le septième paquet à échouer sur un chemin en fin de package()
après une compilation réussie. L'erreur de libpsl nomme son propre correctif.
Assisted-by: Claude Opus 5
meson and cmake both ask the HOST where libraries go. On Ubuntu the
answer is lib/s390x-linux-gnu, so five packages already in the repository
ship theirs where Arch's ld.so and pkgconf never look. Measured:
expat 12 lz4 6 pacman 6 pkgconf 6 zstd 12 entries
Nothing failed. util-linux is where it finally shouted, and even there
the rm was the first victim, not the cause.
pacman is the one that matters: libalpm.so.16 landed where pacman's own
binary cannot load it, and a target installed from that package has no
working package manager left to repair itself with.
arch-meson now states the libdir devtools has no need to state, and is
reinstalled on every run -- editing the copy here changed nothing while
/usr/local/bin held a stale one. Four packages call bare meson or cmake
and get their own hook. util-linux's old hook chased lib64, which never
existed here; it is deleted.
--- FR ---
meson et cmake demandent tous deux à l'HÔTE où vont les bibliothèques.
Sous Ubuntu la réponse est lib/s390x-linux-gnu : cinq paquets déjà dans
le dépôt livrent donc les leurs là où ld.so et pkgconf d'Arch ne
regarderont jamais. Mesuré :
expat 12 lz4 6 pacman 6 pkgconf 6 zstd 12 entrées
Rien n'a échoué. util-linux est l'endroit où cela a fini par crier, et
même là le rm était la première victime, pas la cause.
pacman est celui qui compte : libalpm.so.16 atterrissait là où le binaire
de pacman ne peut pas la charger, et une cible installée depuis ce paquet
n'a plus de gestionnaire de paquets pour se réparer.
arch-meson énonce désormais le libdir que devtools n'a pas besoin
d'énoncer, et se réinstalle à chaque exécution : éditer la copie du dépôt
ne changeait rien tant que /usr/local/bin en gardait une périmée. Quatre
paquets appellent meson ou cmake nu et reçoivent leur crochet. L'ancien
crochet util-linux poursuivait un lib64 qui n'a jamais existé ici : il
est supprimé.
Assisted-by: Claude Opus 5
grep is the only package here that INSPECTS the version of the m4
macros its build host provides, and refuses to proceed:
./bootstrap: do not use pkg.m4 serial 12
That is not an s390x incompatibility -- the same refusal happens on any
Ubuntu host, x86 included. The release tarball is already bootstrapped,
so re-running ./bootstrap regenerates what is already there and
skipping it costs nothing.
util-linux hits the lib64-versus-lib divergence already handled in
gcc.sh. Here it surfaces as
rm: cannot remove '.../usr/lib/lib*.la': No such file or directory
a glob that matched nothing, which rm reports as a missing file rather
than an empty expansion -- so the error names a path that was never
going to exist. Same remedy: merge the trees before package() touches
anything, leaving the upstream paths working unchanged.
That divergence has now appeared twice. If a third package hits it, it
belongs in the shared bootstrap rather than in per-package hooks.
--- FR ---
grep est le seul paquet ici a EXAMINER la version des macros m4 que lui
fournit son hote, et a refuser de poursuivre :
./bootstrap: do not use pkg.m4 serial 12
Ce n est pas une incompatibilite s390x -- le meme refus survient sur
n importe quel hote Ubuntu, x86 compris. L archive de version est deja
amorcee, donc relancer ./bootstrap regenere ce qui existe deja et le
sauter ne coute rien.
util-linux rencontre la divergence lib64 contre lib deja traitee dans
gcc.sh. Elle apparait ici sous la forme
rm: cannot remove '.../usr/lib/lib*.la': No such file or directory
un motif qui ne correspond a rien, que rm signale comme un fichier
manquant plutot que comme une expansion vide -- l erreur nomme donc un
chemin qui n allait jamais exister. Meme remede : fusionner les arbres
avant que package() ne touche a quoi que ce soit.
Cette divergence est apparue deux fois. Si un troisieme paquet la
rencontre, sa place est dans l amorcage partage et non dans des
crochets par paquet.
Assisted-by: Claude Opus 5
