ArchLinux, en Français
Avant la version 3.1-2, il manquait un lien soname dans le paquet astyle. Ce problème a été corrigé dans la version 3.1-2. Par conséquent, la mise à jour devra remplacer le lien soname non suivi créé par ldconfig. Si vous obtenez une erreur
astyle: /usr/lib/libastyle.so.3 exists in
filesystem
lors de la mise à jour, utilisez
pacman -Suy --overwrite usr/lib/libastyle.so.3
pour effectuer la mise à jour.
Il manquait des liens soname dans les paquets tensorflow antérieurs à la version 1.14.0-5. Ce problème a été corrigé dans la version 1.14.0-5. La mise à jour devra donc remplacer les liens soname non suivis créés par ldconfig. Si vous obtenez une erreur comme celle-ci:
tensorflow: /usr/lib/libtensorflow.so.1 exists in filesystem
tensorflow: /usr/lib/libtensorflow_cc.so.1 exists in filesystem
tensorflow: /usr/lib/libtensorflow_framework.so.1 exists in filesystemlors de la mise à jour, utilisez:
pacman -Suy
--overwrite=usr/lib/libtensorflow.so.1,usr/lib/libtensorflow_cc.so.1,usr/lib/libtensorflow_framework.so.1
pour effectuer la mise à jour.
Il manquait un lien soname dans le paquet libbloom antérieur à la version 1.6-2. Ce problème a été corrigé dans la version 1.6-2. Par conséquent, la mise à jour devra remplacer le lien soname non suivi créé par ldconfig. Si vous obtenez une erreur
libbloom: /usr/lib/libbloom.so.1 exists in
filesystem
lors de la mise à jour, utilisez
pacman -Suy --overwrite usr/lib/libbloom.so.1
pour la réaliser.
La mise à jour de mariadb 10.4.6-1 et des versions ultérieures modifie la disposition de la configuration, comme recommandé upstream.
Le fichier de configuration principal
/etc/mysql/my.cnf (et son répertoire d’inclusion
/etc/mysql/my.cnf.d/) est déplacé vers
/etc/my.cnf (et /etc/my.cnf.d/).
Assurez-vous de déplacer votre configuration.
Les services instanciés (par exemple
mariadb@foo.service) ne sont plus configurés dans des
fichiers séparés (par exemple /etc/mysql/myfoo.cnf).
Au lieu de cela, déplacez votre configuration vers des blocs de
configuration suffixé par le groupe dans le fichier de
configuration principal, un pour chaque service. Un bloc devrait
ressembler à quelque chose comme ça:
[mysqld.foo]
datadir = /var/lib/mysql-foo
socket = /run/mysqld/mysqld-foo.sock
...Comme pour toute mise à jour mariadb, le répertoire de données doit être réactualisé. Une fois la nouvelle configuration en place, exécutez:
systemctl restart mariadb.service && mariadb-upgrade -u root -pLe paquet libutf8proc précédant la version 2.1.1-3 avait un lien soname incorrect. Cela a été corrigé avec le 2.1.1-3, la mise à jour devra donc remplacer le lien soname non suivi créé par ldconfig. Si vous obtenez une erreur
libutf8proc: /usr/lib/libutf8proc.so.2 existe dans le
système de fichiers
lors de la mise à jour, utilisez
pacman -Suy --overwrite
usr/lib/libutf8proc.so.2
pour effectuer la mise à jour.
Étant donné que le fichier SONAME de
/usr/lib/libmozjs-52.so ne correspondait pas à son nom
de fichier, ldconfig a créé un fichier
/usr/lib/libmozjs-52.so.0 non suivi. Ceci est
maintenant corrigé et les deux fichiers sont présents dans le
paquet.
Pour effectuer la mise à jour, supprimez
/usr/lib/libmozjs-52.so.0 auparavant.
La nouvelle version de glibc supprime
le support pour NIS et NIS+. Le fichier
/etc/nsswitch.conf par défaut fourni par le paquet
filesystem reflète déjà cette modification.
Assurez-vous de fusionner le fichier pacnew s’il existe avant la
mise à jour.
La fonctionnalité NIS peut toujours être activée en installant
le paquet libnss_nis. Il n’y a pas de remplacement
concernant NIS+ dans les dépôts officiels.
pam 1.3.0-2 n’embarque plus le module pam_unix2 et
les liens symboliques de compatibilité pam_unix_*.so.
Avant de mettre à jour, passez en revue les fichiers
de configuration PAM dans le répertoire /etc/pam.d et
remplacez les modules supprimés par
pam_unix.so. Les utilisateurs de
pam_unix2 devraient également réinitialiser leurs mots de passe
après cette modification. Les valeurs par
défaut fournies par le paquet pambase ne nécessitent
pas de modifications.
Il manquait dans le paquet zita-resampler 1.6.0-1 un lien symbolique vers une bibliothèque qui a été rajouté en 1.6.0-2. Si vous avez installé la version 1.6.0-1, ldconfig aura créé ce lien symbolique au moment de l’installation qui entrera en conflit avec celui inclus dans la version 1.6.0-2. Dans ce cas, supprimez /usr/lib/libzita-resampler.so.1 manuellement avant la mise à jour.
Après 9 mois de dépréciation, le support de l’architecture i686 prend fin aujourd’hui. À la fin de novembre, les paquets i686 seront supprimés des miroirs officiels et plus tard de l’archive des paquets. Le dépôt [multilib] n’est pas affecté.
Pour les utilisateurs qui ne sont pas en mesure de migrer vers du matériel x86_64, une alternative réside dans une branche maintenue par la communauté nommée Arch Linux 32. Consultez leur site Web pour plus de détails sur la migration d’installations existantes.
Le paquet Perl utilise maintenant un chemin versionné pour les modules compilés. Cela signifie que les modules conçus pour une version Perl qui ne correspondent pas ne seront plus chargés et devront être reconstruits.
Un hook de pacman avertit des modules concernés lors de la mise à niveau en affichant comme suit:
WARNING: '/usr/lib/perl5/vendor_perl' contains data from at least 143 packages which will NOT be used by the installed perl interpreter. -> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/perl5/vendor_perl'(NdT: AVERTISSEMENT: '/usr/lib/perl5/vendor_perl' contient des données d'au moins 143 paquets qui ne seront PAS utilisés par l'interpréteur Perl installé. -> Exécutez la commande suivante pour obtenir une liste des paquets affectés: pacman -Qqo '/usr/lib/perl5/vendor_perl' )
Vous devez reconstruire tous les paquets indiqués contre le nouveau paquet Perl avant de pouvoir les utiliser à nouveau. La modification affecte également les modules installés directement via CPAN. La reconstruction sera également de nouveau nécessaire avec les futures mises à jour principales de Perl, telles que 5.28 et 5.30.
Notez que la reconstruction était déjà requise lors des mises à jour majeures antérieures à cette modification, mais désormais Perl n’essayera plus de charger les modules et échouera de façon étrange.
Si le système de construction d’un logiciel ne détecte pas
automatiquement le changement, vous pouvez utiliser perl -V:
vendorarch dans votre PKGBUILD pour interroger Perl sur le
chemin d’accès correct. Il existe également sitearch
pour les logiciels qui ne sont pas préparés avec pacman.