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 ;)
Pourquoi s'embêter à créer un autre gestionnaire de paquets alors que nous en avons déjà tous un ?
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.
Par ailleurs, Lutris et PlayOnLinux remplissent plutôt bien leur rôle et ne cherchent pas à réinventer un gestionnaire de paquets...
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.
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") ?
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).
[^] # Re: Je ne comprends pas
Posté par vv222 . En réponse à la dépêche ./play.it 2.11 : Gentoo, Flatpak et jeux vidéos. É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é.