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.
En raison du coût de
maintenance élevé des scripts liés au Arch Build System, nous avons
décidé de déprécier l’outil abs et par conséquent
rsync comme moyen d’obtenir des PKGBUILDs.
L’outil
asp, disponible dans [extra], offre une fonctionnalité
similaire à abs.asp
export pkgname peut être utilisé comme une alternative
directe;Vous trouverez plus d’informations
sur son utilisation dans
la documentation.De plus, les sparse
checkouts de Subversion, tels que décrits ici, peuvent être utilisés
pour obtenir un effet similaire.Pour
récupérer tous les PKGBUILD, la meilleure manière consiste à cloner
les miroirs svntogit.
Tandis que le paquet
extra/abs a déjà été abandonné, rsync
(rsync://rsync.archlinux.org/abs) sera désactivé d’ici la fin du
mois.
La mise à jour vers ca-certificates-utils
20170307-1 demande une intervention manuelle à cause d’un lien
symbolique précédement généré dans le post-install qui
est maintenant géré proprement dans le paquet.
Supprimer ce lien symbolique n’est pas
recommandé (cela peut entrainer des problèmes de téléchargement de
paquets), et l’upgrade doit se passer en 3 étapes :
mesa-17.0.0-3 peut maintenant être installé côte à
côte avec le driver nvidia-378.13 sans aucun hack
libgl/libglx, grâce au travail de Fedora et les modifications
apportée à xorg-server.
La première étape a été de supprimer les liens symboliques
entre xorg-server (ainsi que les drivers nvidia/mesa)
et libglx via la suppression de divers paquets libgl.
C’était une opération difficile car cela casse les systèmes avec
optimus, la configuration de xorg-server demande
une modification manuelle.
La seconde étape est maintenant là, avec un nouveau fichier
10-nvidia-drm-outputclass.conf qui devrait aider à avoir
un setup xorg-server fonctionnel « out-of-the-box » pour
les systèmes optimus !
En raison de la popularité
décroissante de l’i686 parmi les développeurs et la communauté,
nous [NdT: développeurs et TU d’Arch] avons décidé de supprimer
progressivement le support pour cette
architecture.
Cette
décision signifie que l’iso de février sera la dernière permettant
d’installer Arch Linux 32 bits.Les 9 mois
suivants seront une période de dépréciation, durant laquelle i686
recevra tout de même des mises à jour de paquets.À partir de novembre 2017, les outils d’empaquetage
et de dépôt ne nécessiteront plus de maintenance, ce qui rendra le
i686 non supporté.
Toutefois, comme il y a encore un intérêt à
maintenir le i686 en vie, nous [NdT: développeurs et TU d’Arch] aimerions
encourager la communauté à le faire avec nos conseils.La liste de diffusion arch-ports et
le canal IRC sur Freenode, #archlinux-ports, seront utilisés pour
une coordination ultérieure.
Le dépôt [multilib] ne sera pas affecté par cette
modification.
La mise à jour vers OpenVPN 2.4.0 apporte des modifications
incompatibles avec les configurations précédentes. Faites
très attention si vous dépendez de la connectivité VPN
pour l’accès à distance ! Une intervention
administrative est requise:
La configuration est désormais attendue dans des
sous-répertoires. Déplacez vos fichiers depuis
/etc/openvpn/ vers /etc/openvpn/server/
ou /etc/openvpn/client/.
Le chemin de recherche du plugin a changé, supprimez
plugins/ des chemins relatifs.
L’unité systemd openvpn@.service a été remplacée
par openvpn-client@.service et
openvpn-server@.service. Redémarrez et réactivez en
conséquence.
Ceci n’affecte pas la fonctionnalité de
networkmanager, connman ou
qopenvpn.