Salut à tous les amateurs de jeux vidéos qui apprécient de ne pas sacrifier leur liberté, même lorsqu’il est question de loisirs. ;)
« ./play.it » est une solution libre permettant d’installer très facilement toute une collection de jeux vidéos propriétaires — généralement commerciaux — sur GNU/Linux, que nous avons présentée ici‐même pour la première fois il y a maintenant un an : « ./play.it installe vos jeux sans prise de tête ».
Aujourd’hui, nous vous proposons de jeter un œil sur quelques avancées majeures apportées par la toute fraîche version 2.11, sortie le 26 janvier 2019.
Sommaire
- Sur Gentoo aussi on aime jouer
- En route vers les dépôts de Debian Buster
- Une meilleure gestion des jeux Java
- Flatpak
- Nouveaux jeux
- Journées du Logiciel Libre 2019
Sur Gentoo aussi on aime jouer
Ouvrons notre liste des nouveautés avec la plus grosse : ./play.it permet maintenant d’installer des jeux sur Gentoo !
Cette nouvelle fonctionnalité est très marquante pour nous, pour essentiellement deux raisons :
La première est que nous avons dû passer par une réécriture complète du code la première fois que nous avons ajouté la gestion d’une nouvelle famille de distribution (Arch Linux et dérivées), alors que cette fois‐ci nous avons pu nous contenter d’une mise à jour mineure totalement rétro‐compatible. Ce qui nous prouve que cette réécriture avait été bien pensée, et que l’énergie dépensée lors de celle‐ci continuera à nous faire économiser pas mal de boulot par la suite.
La seconde est que la gestion de Gentoo a été ajoutée à notre code par un développeur seul, BetaRays, qui n’avait avant ça presque jamais touché au code de la bibliothèque. Ce qui est plutôt rassurant sur l’état et la clarté dudit code, surtout quand on prend en compte que la documentation de celui‐ci est encore à venir (une façon de dire qu’on n’a encore rien de ce côté pour l’instant).
Même si cette nouvelle fonctionnalité a été bien testée pendant plusieurs mois, il est impossible qu’aucun bogue ne nous ait échappé, nous serons donc ravis de recevoir vos retours sur notre gestionnaire de tickets si vous rencontrez des problèmes.
En route vers les dépôts de Debian Buster
Grâce au boulot de notre mainteneur chez Debian, Phil Morrell, nous avons rejoint la section « contrib » des dépôts de Debian Sid depuis le 26 juin 2018.
Le gel de Debian Buster étant lancé, nous pouvons maintenant confirmer sans trop de risques de nous planter que nous ferons partie des dépôts de celle‐ci lors de sa publication comme version stable.
Si vous voulez suivre notre propagation dans les dépôts d’un grand nombre de distributions, Repology compile ces informations d’une manière claire. Toute proposition de coup de main pour réduire la liste « Absent in repositories » (absent des dépôts) est bien sûr la bienvenue. ;)
Une meilleure gestion des jeux Java
Jusqu’à ./play.it 2.10 inclus, les jeux Java gérés par ./play.it utilisaient la version de Java fournie dans l’installateur. Donc généralement mal optimisée, périmée, et quelques autres adjectifs disgracieux dans le même genre.
À partir de ./play.it 2.11, il est possible d’écrire des scripts pour des jeux Java qui utiliseront la version de Java fournie par le système.
Pour l’instant, trois jeux utilisent cette nouvelle recette :
Vos retours au sujet de ces jeux sont les bienvenus. Comme ce système est tout neuf, il est possible que des soucis se révèlent sur certaines configurations particulières.
Flatpak
La possibilité de construire des archives Flatpak via ./play.it est une demande récurrente, sur laquelle on n’avait jusqu’ici pas avancé pour cause de manque d’intérêt de la part des contributeurs actifs.
Mais la situation a changé depuis que bam80 a rejoint nos rangs, et a commencé à travailler sur la possibilité d’utiliser ./play.it pour produire des installations de type Application Directory. Cette installation directe dans un répertoire contrôlé par l’utilisateur (et pas un répertoire système, comme c’est le cas avec les formats de paquets classiques) doit servir de première étape pour une future gestion de Flatpak.
Si ce format vous intéresse, le développement a lieu sur une branche dédiée de notre dépôt Git officiel : New feature: Application directory.
L’historique des discussions est dispersé sur ce même dépôt :
- no fallback provided if no package format detected ;
- Distro‐agnostic installation method ;
- Distro‐agnostic install support.
Pour éviter toute confusion, cette fonctionnalité ne fait pas partie de la version 2.11 de ./play.it. Selon la vitesse à laquelle on continuera à avancer, elle pourrait faire partie de la future version 2.12.
Il reste donc du chemin à parcourir avant que ./play.it puisse produire des archives Flatpak, mais les premiers pas ont été faits, et nous attendons avec impatience de nouvelles contributions sur ce front. ;)
Nouveaux jeux
Bon, on se doute bien que ce qui vous intéresse vraiment est la liste des jeux gérés par ./play.it. ;)
Voici donc la liste de ceux qui ont rejoint notre bibliothèque depuis notre dernière dépêche pour la sortie de la version 2.10 :
- Asura ;
- Cornerstone: The Song of Tyrim ;
- Costume Quest ;
- Deadbolt ;
- Deltarune — Chapter 1 ;
- Distance ;
- Enigmatis: The Ghosts of Maple Creek ;
- Enigmatis 2: The Mists of Ravenwood ;
- Enigmatis 3: The Shadow of Karkhala ;
- Everspace ;
- Evoland 2, A Slight Case of Spacetime Continuum Disorder ;
- Fallout ;
- Fallout 2 ;
- Farabel ;
- Fox & Flock ;
- Gone Home ;
- Graveyard Keeper ;
- Grim Legends: The Forsaken Bride ;
- Grim Legends 2: Song of the Dark Swan ;
- Grim Legends 3: The Dark City ;
- Her Majesty’s SPIFFING ;
- Hiveswap: Act 1 ;
- Human Resource Machine ;
- Inner Space ;
- Kero Blaster ;
- Lilly Looking Through ;
- LIMBO ;
- Little Big Adventure ;
- Little Inferno ;
- Lyne ;
- MechaNika ;
- Momodora: Reverie Under the Moonlight ;
- Monster Prom ;
- Moon Hunters ;
- Neverwinter Nights ;
- Niche ;
- Nightmares From the Deep 2: The Siren’s Call ;
- Nightmares From the Deep 3: Davy Jones ;
- Opus Magnum ;
- Papo and Yo ;
- Pink Heaven ;
- Pink Hour ;
- Planescape: Torment ;
- Proteus ;
- Pulse ;
- Rogue legacy ;
- Secrets of Raetikon ;
- Silence ;
- State of Mind ;
- Tag: The Power of Paint ;
- The Cat Machine ;
- The Dig ;
- The Tiny Bang Story ;
- Touhou Kishinjou ~ Double Dealing Character — Demo ;
- Tyranny ;
- Vampire the Masquerade: Bloodlines ;
- Wonder Boy: The Dragon’s Trap.
Quelques‐uns de ces jeux étaient déjà gérés par ./play.it 1.x, leur présence dans cette liste signifie qu’ils sont maintenant gérés par ./play.it 2.x, avec tous les avantages que ça implique. Y compris la possibilité de construire des paquets pour Arch Linux et Gentoo.
Journées du Logiciel Libre 2019
Les Journées du Logiciel Libre, rendez‐vous annuel d’utilisateurs de logiciels libres et de curieux à Lyon, fait partie de nos habitudes depuis quelques années.
Cette année elles auront lieu le week‐end des 6 et 7 avril, nous y présenterons une conférence et y tiendrons un stand pendant toute la durée de l’événement. Pour ceux qui voudraient nous rencontrer, ce sera l’occasion idéale. ;)
Pour plus d’informations, rendez‐vous sur le site officiel des Journées du Logiciel Libre (JdLL).
Profitons de cette annonce pour rappeler que ce genre d’événement est gratuit uniquement pour les visiteurs, et a un coût non négligeable pour les organisateurs comme pour les intervenants. Nous invitons donc ceux qui peuvent se le permettre à participer à l’appel à contribution en cours, qui devrait aider à financer l’édition de 2019 : Contribuons aux Journées du Logiciel Libre.
Une dépêche ici même propose d’autres manières de contribuer si jamais l’aide financière ne fait pas partie de vos possibilités : « Les Journées du Logiciel Libre ont besoin de vous ! ».
Aller plus loin
- Présentation de ./play.it sur LinuxFr.org (149 clics)
- Liste des jeux gérés par ./play.it (299 clics)
- Dépôt officiel sur Framagit (138 clics)
- Nous soutenir financièrement ;) (Liberapay) (37 clics)
- Bottin des jeux GNU/Linux (69 clics)
# et mtp-target dans tout ça ?
Posté par djibb (site web personnel) . Évalué à 4.
une bonne âme pour reprendre le concept, remettre les sources en ligne ?
[^] # Re: et mtp-target dans tout ça ?
Posté par vv222 . Évalué à 3.
Pour ceux comme moi qui ne connaissaient pas Mtp Target, il s’agit d’un jeu qui a été évoqué sur votre site préféré : Libérons les Tux volants
[^] # Re: et mtp-target dans tout ça ?
Posté par papap . Évalué à 3.
De mémoire, le jeu était partiellement libre.
# Perspectives
Posté par flexop . Évalué à 2. Dernière modification le 16 mars 2019 à 12:08.
Je perçois l'enthousiasme que vous portez au projet mais l'essentiel est ce qui importe. Pour ma part, le projet ne me convainc pas.
Simplicité ?
Un logiciel peut implémenter beaucoup de fonctionnalités et être complexe dans l'ensemble mais être simple dans sa composition. Lutris exploite un langage permettant l'abstraction tandis que « PlayIt » utilise un langage shell POSIX (un langage de commandes restreint).
En outre, Lutris est développé intensivement (voyez le dépôt GitHub) et semble plus accessible pour les développeurs (structuration du projet, documentation, débogage…) et pour les utilisateurs (configurations, site web, forum…).
Il s'agit d'une caractéristique particulière à l'implémentation de « PlayIt ». On peut concevoir des logiciels interactifs accessibles pour les utilisateurs.
Portabilité ?
Malheureusement, je ne vais pas vérifier ces affirmations car je ne connais que Gentoo. Toutefois, les « ebuilds » permettent d'intégrer de nouveaux logiciels.
Cette affirmation semble correcte sauf qu'il faut disposer d'extensions adaptées à chaque gestionnaire de paquets.
En conséquence, « PlayIt » est potentiellement inutile pour les distributions. Un contributeur élabore une spécification adaptée à son gestionnaire de paquets plutôt que d'élaborer une spécification particulière à un gestionnaire logiciel lambda.
Gentoo ?
Aucun logiciel n'indexera automatiquement « PlayIt » puisque « l'overlay BetaRays » n'est pas listé par Gentoo. En outre, les overlays ne sont pas supportés par la communauté Gentoo.
[^] # Re: Perspectives
Posté par vv222 . Évalué à 4.
Tant mieux, c’est grâce aux retours de personnes qui ne sont pas convaincues qu’on peut l’améliorer ;)
En effet, c’est un choix d’ergonomie de notre part. Les version 1.x de ./play.it étaient interactives sur certains points, et les versions 2.x ne le sont plus.
Ce qu’on constate c’est que cette absence d’interactivité (sauf par des options qu’on peut passer aux scripts) a bien aidé sur deux points :
Justement, ./play.it sert essentiellement à installer des jeux pour lesquels les développeurs/distributeurs ne proposent pas de paquets Linux natifs. Les jeux ne sont donc pas élaborés d’une manière compatible avec ./play.it, c’est au contraire ./play.it qui se rend compatible avec un maximum de formats qui sont courants dans la distribution de jeux non-libres.
[^] # Re: Perspectives
Posté par flexop . Évalué à 0.
Il n'empêche qu'on doit créer une interface pour « PlayIt » alors qu'on peut écrire directement une spécification pour le gestionnaire de paquets de sa distribution. Un utilisateur pourrait installer facilement un nouveau jeu mais pour ce faire il doit être sûr que « PlayIt » est un générateur de spécifications fiable, ce qui implique d'étudier son implémentation. De plus, vous pourriez aboutir à un résultat moins convenable qu'en employant initialement le gestionnaire de paquets.
[^] # Re: Perspectives
Posté par vv222 . Évalué à 4. Dernière modification le 16 mars 2019 à 16:20.
Je crois qu’il y a un souci de compréhension du rôle de ./play.it ;)
Nous ne gérons pas des jeux libres. Les développeurs/distributeurs de ces jeux ne se soucient pas (ou peux) de l’intégration de ces jeux au sein de nos distributions, et leur inclusion aux dépôts de celles-ci est exclue pour des raisons de licence.
Les développeurs des jeux n’écrivent donc pas d’interface pour ./play.it, ce sont les développeurs de ./play.it qui font ça.
Pour ce qui est de la qualité des paquets générés, je t’invite à tester ./play.it sur un des jeux gratuits qu’on gère (par exemple Tag: The Power of Paint).
Je peux t’assurer que les paquets produits par ./play.it sont bien plus propres que ce que les quelques boutiques en ligne fournissant des paquets natifs proposent.
[^] # Re: Perspectives
Posté par flexop . Évalué à 0. Dernière modification le 16 mars 2019 à 18:15.
Vous réalisez un script utilisant la bibliothèque « libplayit2.sh » de « PlayIt » pour générer des ensembles de spécifications (configurations dédiées fournies) adaptés à chaque gestionnaire de paquets supportés. Ainsi, un jeu MS Windows peut être installé avec le gestionnaire de paquets et être exécuté ultérieurement grâce à l'émulateur WINE, par exemple.
Toutefois, on peut certainement installer un jeu uniquement avec le gestionnaire de paquets de sa distribution (en ce qui concerne Gentoo). Pour finir, Lutris semble beaucoup plus puissant et simple d'utilisation.
[^] # Re: Perspectives
Posté par papap . Évalué à 5.
Je veux les deux : à la fois Lutris et Playit. M'en fout si l'un est moins bon que l'autre. Si ça peut aider la jouabilité sous Linux de plein de jeux qui viennent de partout, c'est tout bénéf.
[^] # Re: Perspectives
Posté par BetaRays . Évalué à 2.
Gentoo n'a pas beaucoup de jeux commerciaux il me semble, et ./play.it n'est pas uniquement utile pour faire fonctionner les jeux facilement, il permet aussi de placer les sauvegardes des jeux automatiquement dans des dossiers standards par exemple.
L'avantage de faire un script ./play.it est qu'il fonctionnera sur toutes les distributions supportées sans avoir besoin de faire quelque chose de différent pour chaque distribution.
Je ne connais pas lutris, mais il a l'air d'être beaucoup trop gros pour moi (avec trop de dépendances…), est-ce qu'il installe les jeux globalement ? J'utilise ./play.it aussi pour pouvoir jouer aux jeux avec un utilisateur séparé plus facilement (oui je cherche un peu trop la sécurité…).
[^] # Re: Perspectives
Posté par papap . Évalué à 4. Dernière modification le 16 mars 2019 à 19:38.
Et vive PlayonLinux aussi
[^] # Re: Perspectives
Posté par BetaRays . Évalué à 2.
J'ai fait un overlay parce qu'il faut maintenant ajouter le nom légal dans les commits en tant que proxy maintainer sur le repo gentoo (https://www.gentoo.org/glep/glep-0076.html), même si ça aurait été beaucoup plus simple de mettre les ebuilds directement dessus.
Pour la visibilité de l'overlay, je pourrais certainement ouvrir un bug sur le bugzilla pour l'ajouter à la liste des overlays.
# Commentaire supprimé
Posté par sophieT . Évalué à 1. Dernière modification le 16 mars 2019 à 15:54.
Ce commentaire a été supprimé par l’équipe de modération.
# Flatpak
Posté par yabb85 . Évalué à 2.
Bonjour,
Est ce que flatpak sera la pour pallier a toutes les architectures non supporté ou juste un palliatif? Je m'explique. J'ai une fedora mais les RPM ne sont pas supporté par play.it. Est ce que flatpak sera la façon officielle de supporter les RPM ou la partie RPM devra être rajouter plus tard et flatpak permet temporairement de fonctionner sur fedora?
Merci
[^] # Re: Flatpak
Posté par vv222 . Évalué à 6. Dernière modification le 18 mars 2019 à 09:03.
Les RPM sont dans notre TODO-list, ce qui je pense répond à ta question ;) (cf. Add ability to build RPM packages)
J’ai connaissance de quelques autres personnes intéressées par ce format, reste juste à constituer et coordonner une petite équipe, ça pourrait être l’affaire de quelques mois seulement avant que ./play.it n’apprenne à produire des paquets RPM.
Pour être plus clair sur la question d’origine, je vois la gestion de Flatpak comme remplissant deux rôles :
Donc Flatpak ne servira pas à justifier l’absence d’un autre format de paquets.
En fait de mon point de vue rien d’autre ne pourra être utilisé pour justifier ça, que le manque d’un contributeur motivé ;)
Petite précision probablement pas inutile : chaque contributeur bosse sur la partie du projet qui l’amuse, ce qui veut dire en particulier que la personne bossant sur Flatpak n’est de toutes façons pas quelqu’un qui aurait bossé sur la gestion d’un autre format de paquet.
Flatpak n’est donc pas en train de "piquer" de la main d’œuvre à d’autres parties du projet.
# Je ne comprends pas
Posté par Nibel . Évalué à 3. Dernière modification le 18 mars 2019 à 14:49.
Depuis 2017, je ne comprends toujours pas l'intérêt de play.it… J'ai l'impression que vous cherchez à réinventer la roue.
Quel est son intérêt par rapport à makepkg/AUR par exemple ? Il aurait à la limite été intéressant de créer une lib basée sur makepkg pour les distributions qui n'ont pas ces outils… Pourquoi s'embêter à créer un autre gestionnaire de paquets alors que nous en avons déjà tous un ?
D'autant plus qu'avec l'arrivée de Steam Play / Proton, il n'a jamais été aussi simple de jouer à ses jeux Windows (du moment que l'on possède un compte Steam, j'entends bien).
Par ailleurs, Lutris et PlayOnLinux remplissent plutôt bien leur rôle et ne cherchent pas à réinventer un gestionnaire de paquets…
Concrètement, que fait play.it qui ne pourrait être fait avec makepkg/AUR (ou une lib basée sur makepkg, on pourrait imaginer "makedeb") ? Quels sont ses avantages/inconvéniants par rapport à Lutris et PlayOnLinux ?
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Je ne comprends pas
Posté par Zatalyz (site web personnel) . Évalué à 6.
Je vais apporter une réponse de joueuse (je ne contribue pas au code de ./play.it).
Déjà à propos de Steam et compagnie, pour moi c'est juste niet sur mon linux. Si je veux me faire pister, je rallume ma xbox ou windows, mais si j'ai choisi d'avoir pour OS principal un linux, c'est en partie pour limiter les indiscrétions des grosses entreprises. C'est un choix personnel, mais tout ce qui me permet d'éviter les solutions de type Steam me vont bien. Certes, j'installe des jeux propriétaires sur mon joli linux mais vu leur âge je crains pas trop que les jeux en question me pistent !
Et c'est quand même confortable de pouvoir jouer à Caesar tout en profitant de mon environnement de bureau favori.
Ensuite, par rapport PlayOnLinux (je n'ai pas testé Lutris), ou même les installateurs "linux" sur Gog, j'apprécie justement ce côté gestionnaire de paquet. En passant par ./play.it, je sais que toutes les données du jeu sont installées d'une façon cohérente sur mon système, je sais où aller chercher les config et le jour où je veux désinstaller, c'est les commandes de base de mon gestionnaire de paquet donc facile. Il m'est arrivé d'installer des jeux gog sans passer par ./play.it (puisqu'il y avait un installateur linux, un joli .sh) et ça a généralement été le bordel ensuite, parce que wine était mal configuré, parce que des dossiers bizarres apparaissaient n'importe où, et parce que pour désinstaller ce bazar… bah je retrouve encore des miettes ici et là. Pour moi, que le jeu soit un paquet comme un autre, c'est en accord avec la façon de gérer mon ordi. Mais là aussi, je conçois qu'on s'en moque, tout le monde n'a pas les mêmes lubies ;)
Par rapport à AUR, peut-être qu'effectivement le comportement de ./play.it pourrait être inclus dans AUR (c'est assez proche), mais ça sent le yakafokon : "yaka trouver des mainteneurs pour le faire". Il est même probable que ça ne demande pas trop de boulot, à partir du moment où on s'y connait ; là aussi, "yaka" proposer. En attendant, les scripts de ./play.it ont des fonctionnements assez similaires, et ce que j'ai installé via ./play.it est listé par trizen donc ça fait pas grosse différence pour moi…
[^] # Re: Je ne comprends pas
Posté par vv222 . Évalué à 7.
Zatalyz a déjà parfaitement expliqué pourquoi Steam n’est pas une option pour nous, et a bien montré en quoi ./play.it est plus différent de PlayOnLinux qu’on pourrait le penser, je vais donc répondre aux autrs points ;)
Avant tout, je pense qu’on n’utilise pas le même sens pour « gestionnaire de paquets », vu que le but de ./play.it est de se passer d’un nouveau gestionnaire de paquets en utilisant des formats déjà bien établis.
Je vais donc comprendre ça comme « générateur de paquets », mais n’hésite pas à me corriger si jamais je t’ai mal compris ;)
De ton message, je comprends que tu es utilisateur d’Arch Linux. En effet, un utilisateur de Debian nous aurait plutôt demandé pourquoi on se casse la tête plutôt que de se baser sur dpkg, quitte à construire des bibliothèques autour pour que d’autres distributions l’utilisent…
Je pense que tu vois le souci qui se présente ici, chacun prêche pour sa chapelle (moi le premier, je suis un grand fan de dpkg et apt) au détriment de la diversité qui fait selon moi du Logiciel Libre.
Un autre souci avec les générateurs de paquets existants est qu’ils sont tous conçus essentiellement autour de l’accès au code source des applications, chose qui est bien sûr exclue dans notre cas.
Je ne reviendrai pas sur PlayOnLinux, par contre Lutris est un bon exemple des raisons qui m’ont poussé à créer ./play.it.
Lutris est un client "tout en un", qui va gérer ton application du téléchargement de l’installateur original jusqu’au lancement. Ce fonctionnement est opposé aux idées même derrière la conception de ./play.it, qui ne cherche pas à imposer, ni même à proposer, une manière de gérer ses jeux passé l’installation.
Des clients complets on n’en manque pas, mais à chaque fois il faut utiliser tout le lot ou s’en passer complètement. ./play.it est à ma connaissance le seul projet avec game-data-packager à pouvoir être utilisé comme brique de base pour construire un système modulable.
Si nous ne fournissons pas autant de fonctionnalités que Lutris ce n’est donc pas par manque d’ambition, mais parce que nous avons une vision différente plus proche de l’esprit KISS. Les utilisateurs de ./play.it utilisent tous des méthodes différentes pour lister/trier/lancer leurs jeux, selon ce qui est le plus ergonomiques pour eux.
Nous ne visons tout simplement pas le même public.
Contrairement à makepkg/AUR, ./play.it n’est pas spécifique à Arch Linux.
Contrairement à makedeb, ./play.it existe déjà ;P
Et bien sûr, en étant spécialisé sur la construction de paquets pour des jeux vidéos, la rédaction d’un script ./play.it dans ce but est bien plus adaptée et bien plus simple que celle d’un fichier PKGBUILD.
J’en veux pour preuve qu’une partie de nos contributeurs ne sait coder dans absolument aucun langage, pas même en Shell POSIX (langage utilisé pour nos scripts).
À titre de comparaison, le script ./play.it :
https://framagit.org/vv221/play.it/raw/master/play.it-2/games/play-bastion.sh
Et les deux PKGBUILD remplissant (une partie de) son rôle :
https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=bastion-hib
https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=gog-bastion
Sur le coup le seul avantage des PKGBUILD est la concision, et c’est au prix de la compatibilité (Arch Linux uniquement, certaines versions du jeu uniquement), de la lisibilité et de la complexité.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.