L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Une bibliothèque Steam conservée sous /var disparaît du client bêta Linux, avec ses jeux installés affichant un bouton Installer au lieu de Play et le propre journal du client appelant chaque lecteur monté « non monté ». Simon McVittie, développeur Steam Runtime chez Collabora et non chez Valve, a expliqué sur le tracker de Valve pourquoi le journal est correct : à l’intérieur du conteneur dans lequel le client s’exécute désormais, ces lecteurs sont réellement absents.
« Dans le conteneur dans lequel le client Steam s’exécute désormais, il est véritablement vrai que cet emplacement n’est pas monté, car /var/games ne figure pas sur la liste des chemins partagés pour le framework de conteneur, donc par défaut, il n’est pas visible à l’intérieur du conteneur », a écrit McVittie le 19 octobre.
Le rapport derrière cette réponse a été déposé le 16 octobre par un propriétaire exécutant Debian sid sur la version client 1792110651, avec ses bibliothèques sur les ensembles de données ZFS sous /var/games. Tous ont disparu, à l’exception de celui par défaut, ils ont cessé d’apparaître dans les paramètres de stockage de Steam et le journal a nommé quatre dossiers comme non montés tandis que df et mount les montraient tous deux montés. Valve a étiqueté le rapport « Client Steam » et « Runtime » et n’a rien dit à ce sujet.
Cinq répertoires fonctionnent, et /var n’en fait pas partie
« Si les partitions/ensembles de données de votre bibliothèque étaient montés sous un chemin normalement partagé, comme /mnt, /srv, /media, /home ou même /opt, alors ils fonctionneraient normalement », a écrit McVittie. Il préfixe ces cinq éléments avec « j’aime », ce sont donc ses exemples plutôt que la liste complète, mais déplacer une bibliothèque sous l’un d’eux est la réponse pratique pour l’instant.
/var est un cas plus difficile qu’un répertoire inconnu, dit-il dans un deuxième commentaire : « diverses bibliothèques et outils codent en dur les chemins ci-dessous /var, et dans le conteneur, ces emplacements devront correspondre aux fichiers /etc et /usr du conteneur, pas à ceux de l’hôte ». L’ajout de /var/games à la liste partagée est possible en principe, mais il le décrit comme « principalement utilisé par les jeux emballés dans des distributions Linux », avec le serveur openarena et nethack de Debian comme exemples, « ce n’est donc peut-être pas l’emplacement le plus approprié pour stocker les dossiers de la bibliothèque Steam appartenant à un utilisateur ordinaire ».
Le conteneur lui-même est le changement de Valve, à partir du 15 octobre
Les notes du client bêta de Valve du 15 octobre indiquent que « le client Steam s’exécute désormais dans un conteneur Steam Runtime », ce qui « aidera le client Steam à fournir une expérience plus cohérente sur plusieurs distributions » et est « la même technologie utilisée par les jeux Steam ». La même version est celle qui a fait du client Linux une application 64 bits.
McVittie a également séparé cela d’un rapport plus ancien, 13007, dans lequel un propriétaire conservait une bibliothèque dans un répertoire personnalisé de niveau supérieur sans objectif documenté. Celui-ci est fermé, et la différence, selon ses mots, est que /var a un objectif spécifique.
Le conteneur peut atteindre le disque, Steam n’y regarde tout simplement pas
« Le client Steam conteneurisé a techniquement accès à l’ensemble du système de fichiers hôte », a écrit McVittie, « mais il ne sait pas actuellement accéder à un emplacement non partagé comme /var/games/steam1 en tant que /run/host/root/var/games/steam1. Je ne sais pas si l’équipe du client Steam prévoit d’ajouter cette fonctionnalité. » Il travaille pour Collabora, c’est donc un développeur qui dit qu’il ne sait pas, pas Valve qui ferme la porte.
Le journaliste a sa propre solution de contournement, une variable d’environnement qui répertorie les chemins de sa bibliothèque vers le framework de conteneurs, et il est clair sur sa position : « Je viens de trouver une solution de contournement pour le bug… qui doit encore être corrigé ». Valve lui-même a répondu à une question de stockage différente ce mois-ci, disant à un propriétaire qu’un jeu sur un lecteur exFAT ne démarrerait pas car Proton ne pouvait pas prendre en charge ce système de fichiers.
Le rapport est ouvert et la seule réponse publiée est une liste des répertoires qui fonctionnent.