Bonjour,
Je souhaite distribuer un de mes projets pour la plateforme GNU/Linux.
Le logiciel compile et s’exécute parfaitement sur Debian testing. La seule dépendance nécessaire est Qt5 en plus de la bibliothèque standard.
Après quelques recherches je suis tombé sur plusieurs options possibles :
- livrer le code source
- générer des paquets de distributions (deb, rpm, etc.)
- créer une application portable (AppImage, Flatpack, etc.)
J’explique ci-dessous les avantages et inconvénients de chacune des solutions pour mon projet.
Livrer le code source.
Facile, on crée une archive des sources avec des instructions pour construire le logiciel et hop c’est fait.
Dans mon cas, le logiciel a besoin du SDK VST de Steinberg qui ne peut pas être redistribué par un tiers. Donc les potentiels candidats doivent se le procurer. Une alternative est l’utilisation de VeSTige (aeffectx.h) créé par LMMS, mais je ne l’ai pas encore testé.
Générer des paquets de distributions
Dans cette solution il est question de générer pour chaque distribution un paquet avec des binaires et des spécifications pour les dépendances requises.
Il me semble que cela demande un travail énorme pour rentrer officiellement dans les dépôts des distributions (en tout cas pour Debian). De plus il va falloir avoir les différentes distributions installées pour tester les déploiements.
L’idéal serait d’avoir des gens pour le faire à ma place, mais vu le faible public de mon projet je ne mise pas dessus pour l’instant (même si certains s’en sortent bien apparemment).
De plus il se pose aussi le même problème d’utilisation du SDK VST de Steinberg que pour la solution précédente.
Créer une application portable
Une application portable est un binaire statique qui empaquette le logiciel et ses dépendances. Cela permet d’être indépendant de l’environnement dans lequel est exécuté l’application.
J’utilise un système similaire pour la version Windows (compilation en statique) et cela permet de faire tourner la version 32 bit et 64 bit du logiciel en parallèle. Même si l’exécutable grossit considérablement, cela reste acceptable dans mon cas.
Il en existe apparemment un grand nombre :
- AppImage, recommandé par Linus Torvald
- Guix, soutenu par le projet GNU
- Snap
- CDE
- flatpak, très en vogue en ce moment
Conclusion et questions
Actuellement j’ai laissé de côté la génération des paquets. J’ai peur que ce soit trop chronophage sans garantie de résultat.
La livraison des sources est trivial, et donc je vais me pencher sur les applications portables. Mais quel format choisir ?
Pour ceux qui ont déjà été confrontés au problème de distribuer un logiciel sous GNU/Linux, qu’en pensez vous ?
Merci
# Ne te prend pas la tête
Posté par David Demelier (site web personnel) . Évalué à 10.
Personnellement, je te conseille de ne pas te poser de questions. Fournis ton application en code source avec les fichiers qui vont bien (LICENSE, README, INSTALL, etc).
Ce n'est pas à toi de t'occuper de générer un paquet pour les trillions de distribution qui existent.
Comme tu l'as dit, flatpak semble l'alternative la plus viable, et c'est la seule qui doit être maintenue par l'auteur du logiciel. À voir si ça va vraiment marcher.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ne te prend pas la tête
Posté par louiz’ (site web personnel) . Évalué à 7.
C’est quoi que tu détestes ? Avoir un dossier « packaging » qui ne te sert à rien, quand tu fais un git clone… ? C’est si génant que ça ?
(Oui, je demande parce que c’est ce que je fais)
[^] # Re: Ne te prend pas la tête
Posté par David Demelier (site web personnel) . Évalué à 8. Dernière modification le 05 octobre 2016 à 09:56.
Premièrement, pour les mêmes points cités plus haut, je ne suis pas sûr que les packagers des distributions vont utiliser tes modèles pour leur paquets. Si ça se trouve, la distribution X a décidé de changer d'emplacement pour installer de la doc, manque de bol t'es pas au courant, ton .spec/debian/PKGBUILD/whatever est obsolète et invalide. Le packager va créer le sien pour éviter ce genre d'obsolescence.
Aussi, si tu n'as pas sous la main toutes les distributions que tu maintiens dans ton application, tu ne peux pas tester tes fichiers de construction de paquets et garantir leur bon fonctionnement. Résultat : l'utilisateur ou packager qui s'en sert voit que ça fonctionne pas. Ça va l'agacer, il va se plaindre (ou envoyer un bugreport) et ça va faire du boulot de maintenance pour toi. Alors qu'au départ, si tu délègues complètement cette tâche, tu n'as aucun souci.
Less is more, comme dit. Tu imagines si tu maintiens 50 distributions dans ton dépôt ? J'ose pas imaginer le bordel.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ne te prend pas la tête
Posté par louiz’ (site web personnel) . Évalué à 4.
Ok.
Perso, je build automatiquement les paquets à chaque push sur mon dépôt git (j’utilise le ci de gitlab pour ça), par exemple les RPM pour fedora, dans mon projet biboumi
.
Ça me sert à plusieurs choses :
make installinstalle bien la doc, ou ce genre de choses.J’utilise gitlab-ci, et je build mon truc sur fedora et debian (et bientôt sur openBSD, quand j’aurai le temps d’installer mes outils dans la VM). Si la méthode pour générer un .deb n’était pas hyper chiante, j’aurais fait le même process pour génerer un .deb à chaque push automatiquement. Ça aurait servi à vérifier que mon logiciel est également packageable correctement sous debian, et ça aurait pu aider un potentiel packageur debian à se lancer (en voyant que le travail est fait à 95%, ça peut motiver).
Oui, c’est du travail. J’ai passé du temps à automatiser mes trucs, et j’ai passé du temps à essayer de build des .deb (et un jour je vais peut-être réussir). Mais c’est peut-être plus pratique d’avoir la partie « installation, au sein d’un paquet » dans mon processus d’integration continue, plutôt que de fournir mon code sans jamais tester de le packager, et me taper des bug report d’un packager archlinux qui viendrait me dire « ton makefile est pété, ça n’installe pas la doc ». Ou pire, de jamais être packagé dans aucune distro parce que mon “make install” est juste complètement pété décident d’abandonner mon logiciel parce qu’il serait trop chiant à packager dans leur distro.
Donc non, les .spec et l’eventuel dossier debian/ que je fournis dans mon repository git, ça ne sert pas à me prétendre maintainer de paquets dans les distros associées, ça sert à vérifier que mon logiciel est correct, et motiver un éventuel vrai packageur.
Ah oui, alors ça, si quelqu’un veut bien me faire un machin
debian/qui fonctionne, le builder lui-même à chaque fois que je push sur git (en étant réactif, si possible) et venir m’annoncer quand j’ai cassé un truc dans mon makefile, ça m’intéresse beaucoup. J’aimerais bien déléguer ça. Sinon j’peux aussi le déléguer à gitlab CI.[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 4.
Tu peut les mettre dans des branches séparées de ton dépôt. Ça apporte pas mal de choses, comme le fait de pouvoir faire vivre les packagings de manière indépendante. Par exemple si tu rencontre un bug dans ton paquet gentoo, tu peux le modifier et le taguer sans toucher au reste.
Ça se voit bien chez debian justement, qui met 2 numéros de version à chacun de ses paquets (celui du logiciel et celui du paquet).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par louiz’ (site web personnel) . Évalué à 2.
Au contraire, je vois pas du tout ce que ça apporte.
Le packaging suit de près le code du logiciel, ils ne sont pas indépendants. Par exemple si je rajoute une page de man, je vais mettre à jour le .spec du même coup. Si je rencontre un bug dans mon paquet, ben je peux le modifier sans toucher au reste : il suffit que j’édite le fichier du paquet et pas le reste…
Et si je release une nouvelle version, il faut de toute façon que je mette à jour ce numéro dans le .spec.
Oui, chez fedora aussi. Et je fais ça : le numéro du logiciel est dans le CMakeLists.txt, et le numéro du paquet est dans le .spec.
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 5.
Si tu as 2 numéros de version, c'est bien que tu as des cycles de vie différents. Et dans ta situation le cycle de vie des différents paquets se marchent sur les pieds. Quel nom donne tu aux tags du coup ? La suite de tout tes numéros de version ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par louiz’ (site web personnel) . Évalué à 1.
Non j’ai pas de cycle de vie différent. Je tag les releases du logiciel et c’est marre. Le .spec qui marche avec la 3.0, c’est celui qui est présent dans le dépôt git au tag 3.0. Si y’a un bug dans le .spec je le corrige et voilà, si c’est assez dramatique pour nécessiter une nouvelle release, je fais une 3.1 (ce qui ne sera jamais le cas). J’ai pas besoin de faire des tags spéciaux juste parce que y’a des « numéros » dans le fichier .spec.
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 4.
Pourquoi tu as 2 numéros de version alors ? Ils représentent quoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par louiz’ (site web personnel) . Évalué à 0.
Une convention qui a du sens si le paquet est dans des dépôts quelque part (genre ceux de fedora).
Mais dans mon cas, le numéro du paquet ne sert à rien, à part suivre la convention, et faire que ça build (je pourrais laisser
-1)Le changelog non-plus ne sert à rien. Il est là parce que sinon ça ne build pas.
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 4.
Donc oui, mais ça fonctionne bien parce que tu ne cherche pas à avoir une quelconque traçabilité sur ton packaging (le fait qu'il soit dans un gestionnaire de version n'est que pour un coté pratique puisque tu ne versionne pas ton packaging1. Si tu cherchais à le faire (pour pouvoir reproduire n'importe quel version de tes package facilement), tu ne voudrais probablement plus faire évoluer le numéro de version du logiciel principal.
il se trouve dans un gestionnaire de version, mais il n'a pas de numéro de version permettant de l'identifier, ni de tag. ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par BAud (site web personnel) . Évalué à 3.
l'aide d'un packager debian te permettra de compléter ce qui pourrait manquer (si tu as suivi la doc' de packaging, 95% du boulot est déjà fait, voire tu pourrais postuler comme packager debian :D).
normalement, tu as un .AUR opérationnel, pour Gentoo tu n'es pas loin d'avoir un ebuild opérationnel ;-)
ça c'est un peu mort pour les distros regardantes (Fedora, Debian…), ya pas un équivalent en libre ?
[^] # Re: Ne te prend pas la tête
Posté par mzf (site web personnel) . Évalué à 2.
Si, il existe une version générée par rétro-ingénierie : VeSTige utilisée par le projet LMMS.
Mais comme indiqué dans la doc (
simple header to allow VeSTige compilation and eventually work), ce n’est pas garanti de fonctionner. Je préfère donc utiliser le SDK officiel.[^] # Re: Ne te prend pas la tête
Posté par louiz’ (site web personnel) . Évalué à 2.
Évidemment. J’attends ce messie avec impatience. :P
[^] # Re: Ne te prend pas la tête
Posté par gouttegd . Évalué à 10.
J’abonde en ce sens. Et j’ajouterais, pêle-mêle :
vst-preset-generator-X.Y.Z.tar.gz) ;READMEou dans un fichier annexe genreINSTALL,HOWTO_BUILDou assimilé), et non pas uniquement sur le site web du projet ;src/how_to_compile.txt) ;README.PACKAGERSou assimilé.[^] # Re: Ne te prend pas la tête
Posté par gouttegd . Évalué à 10.
J’oubliais :
.desktoppour l’intégration du programme dans les menus de l’environnement de bureau ; certains empaqueteurs prennent le temps d’écrire eux-même un tel fichier quand le développeur upstream ne le fournit pas, mais autant leur mâcher le travail.[^] # Re: Ne te prend pas la tête
Posté par mzf (site web personnel) . Évalué à 4.
Merci pour tous ces conseils, je vais en profiter pour remanier les sources !
Pour le format des tarballs est-ce qu’il faut forcément générer un
tar.gz? ou un la méthode de compression n’importe pas ?[^] # Re: Ne te prend pas la tête
Posté par David Demelier (site web personnel) . Évalué à 6. Dernière modification le 05 octobre 2016 à 11:27.
Le .tar.gz c'est clairement le plus connu. En terme de compression je pense qu'il est un peu à la ramasse. Je vois (et j'utilise) beaucoup de .tar.xz en ce moment.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ne te prend pas la tête
Posté par gouttegd . Évalué à 5.
J’ai cité .tar.gz parce que c’est le premier qui me vient à l’esprit, mais ça peut être du .tar.gz, du .tar.bz2, du .tar.xz, peu importe.
[^] # Re: Ne te prend pas la tête
Posté par Liorel . Évalué à 3.
C'est à vérifier, mais de mémoire, si tu fais un
tar -xf monfichier.tar.*avec une version récente de tar, il choisit automatiquement l'algorithme de décompression approprié. Donc je ne m'inquièterais pas trop de la méthode de compression ;). Prends simplement celle qui fournit la meilleure compression. Après, ça peut aussi ne même pas valoir le coup de compresser : si ton archive ne fait que quelques Ko, c'est beaucoup de prise de tête pour rien et un tar tout court fera tout aussi bien l'affaire.Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 10.
En fait c'est même assez vieux :
Après avec git tu peux simplement utiliser git archive.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 0.
Je trouve ça bizarre qu'on fasse du logiciel libre sans se préoccuper de comment il est distribué (sauf si on utilise la licence WTFPL, bien sûr). C'est quand même la base du logiciel libre, de pouvoir distribuer les choses. Est-ce qu'il est nécessaire/utile/constructif de sous-traiter ça aux responsables de paquets des différentes distributions? C'est un peu la solution de facilité, non?
[^] # Re: Ne te prend pas la tête
Posté par Cheuteumi . Évalué à 1. Dernière modification le 05 octobre 2016 à 11:40.
Justement, c’est libre, donc on est libre de ne distribuer que les sources et non les binaires.
Dépendant de la complexité du soft, ça prend plus ou moins de temps de faire les paquets, mais ce qui est sûr c’est que devoir maintenir des binaires pour au moins Debian 7, 8, pour RedHat/CentOS 6, 7, pour Ubuntu 14, 15 et 16 et ce au moins dans les architectures i686 et x86_64… ça fait du boulot et même pour un soft tout simple, c’est chronophage.
Et comme dit plus haut, devoir maintenir ces paquets l’est encore plus. Sans parles des dépendances…
Beaucoup de projets adoptent la release des binaires sous la forme de tar.gz, ou d’un paquet pour une distribution, ce n’est pas pour rien. Et la création de flatpak & cie n’est pas sans raison non plus.
Bref, c’est un travail qui est bien mieux entre les mains de personnes qui ne vont s’occuper du packaging que pour une distro en particulier. Ou de ceux qui ont le temps et l’envie de le faire, mais surtout le temps.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 05 octobre 2016 à 11:41.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 9.
Bim ! Dans ta face sale devops de mes 2 !
:)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 5.
C'était plus humoristique qu'autre chose
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par Marotte ⛧ . Évalué à 8.
Il fait péter le correcteur parce que « empaquetage » existe et semble être le mot que tu cherchais ;)
[^] # Re: Ne te prend pas la tête
Posté par freem . Évalué à 1. Dernière modification le 06 octobre 2016 à 09:31.
Oups, pas vu qu'il y a la même réponse un peu plus haut…
[^] # Re: Ne te prend pas la tête
Posté par barmic . Évalué à 5.
Une technique consiste à les mettre dans une autre branche du dépôt.
docker ça le fait aussi :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne te prend pas la tête
Posté par Zenitram (site web personnel) . Évalué à 3.
Vu le commentaire et sa note, clair qu'il n'y a vraiment pas besoin d'ennemis pour flinguer Linux sur le desktop, ses amis s'en chargent, en motivant les gens à ce que seul les "connaisseurs" (peu nombreux sur le desktop) puissent avoir le droit d'utiliser.
Windows, Mac, Android, iOS… avec leurs logithèque prête à l'emploi, ont encore une longue vie, voulue par les amis de Linux.
PS : bon, en pratique il y a quand même du monde qui essaye de contourner ces "amis", mais la route est longue, on voit ici la résistance à accepter des gens ne sachant pas et ne voulant pas mettre la main dans le cambouis.
[^] # Re: Ne te prend pas la tête
Posté par Adrien . Évalué à 4.
Je plussois complètement. Étant confronté à des logiciels libre qui ne fournissent qu'un code source à peine compilable, je trouve que fournir uniquement le code veut simplement dire RAF de l'utilisateur non développeur.
[^] # Re: Ne te prend pas la tête
Posté par BAud (site web personnel) . Évalué à 1.
o_O t'as le code source, ça compile, tu le lances et zou, spa compliqué !
cela permet de recruter ceux qui ont réussi à la compiler (hypothétiquement, ils pourront contribuer).
Un développeur, bin il développe, un packageur, bin il package et envoie les patchs afférents, l'utilisateur, bin il fait avec…
[^] # Re: Ne te prend pas la tête
Posté par David Demelier (site web personnel) . Évalué à 2.
Et bien si ça ne compile pas, tu envoies un bug report. Ça c'est la faute du développeur et il n'aura pas à l'ignorer ;)
Personnellement, je m'assure que mon application compile sur Linux, FreeBSD et Windows (vs et mingw).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ne te prend pas la tête
Posté par Octabrain . Évalué à 5.
Non, si ça compile pas, tu laisses tomber ce projet pourri/pas maintenu/pas testé (rayer les mentions inutiles, ou les garder les 3), sans t'emmerder et t'en cherches un autre, sauf si vraiment y'a rien d'autre.
# Open build service
Posté par Gabbro . Évalué à 10.
Je crois que Zenitram utilise OpenBuildService. L'idée, si j'ai bien compris, c'est de faire un rpm source, la forge interprète tout ça comme il faut et te ressort un dépôt et des paquets pour debian, opensuse, ubuntu, fedora, archlinux et quelques autres. Je n'ai jamais fait, mais pour distribuer un programme sous Linux, ça à l'air franchement pas mal.
[^] # Re: Open build service
Posté par mzf (site web personnel) . Évalué à 3.
Effectivement ça a l'air vraiment super.
A voir en pratique si utiliser un serveur dédié n'est pas trop lourd pour un petit projet. Ceci dit ils ont l'air de fournir des machines virtuelles prêtes à l'emploi.
[^] # Re: Open build service
Posté par Gabbro . Évalué à 3.
Ils fournissent une instance. Ça peut servir à tester.
[^] # Re: Open build service
Posté par Zenitram (site web personnel) . Évalué à 10.
On utilise effectivement OBS.
Avec plus ou moins de bonheur (l'instance publique est parfois capricieuse), mais globalement c'est sympa.
donc on a un VM Windows sous Linux, un Mac chez moi, et OBS, le tout automatisé et on arrive même a faire des nighlies avec OBS.
source de nos outils pour automatiser (pas beau mais ca marche)
bon courage, ca reste pas facile (et surtout ca change souvent même dans une même distro cf Ubuntu) et on doit subir les gens qui dise "fait pas, c'est aux autres" (mais évidement qui ne fournissent pas "autres", comme par hasard, donc en gros ils sont en pratique fiers de dire "merde" a tes utilisateurs non passionnés par la ligne de commande, soit la grosse majorité des gens) quand l'utilisateur est au centre de nos préoccupations.
Note : mes builds Linux sont peu utilisés, certes, mais parfois utilisés par des "pros" ne sachant pas compiler, voulant du facile à tester, et ca m'a amené des contrats ensuite. Pas sur aue je les aurait eu si j'avais pas fait ces builds (et ne pas compter sur les distros, elle ont 6 mois a 2 ans de retard, pas gérable pour les gens "qui payent").
[^] # Re: Open build service
Posté par mzf (site web personnel) . Évalué à 3.
Merci de partager tous ces outils !
[^] # Re: Open build service
Posté par Adrien . Évalué à 3.
Je profite du sujet : tu n'as pas de problème avec les distributions ? genre une distribu qui te reprocheraitde ne pas respecter pas telle procédure de telle distrib, que ça casse ceci ou cela, etc. ?
[^] # Re: Open build service
Posté par Zenitram (site web personnel) . Évalué à 7.
en préambule : qu'elles me reprochent quelque chose m’indifférerait complètement, une distro permet de faire x, je le fais et voila. Aux utilisateurs de me sanctionner si ça ne va pas comme ils aiment, je n'ai aucun compte à rendre aux distros (tout comme elles n'ont aucun compte à me rendre même si je ne me prive pas de les critiquer).
La chose dite, maintenant soyons sérieux : l’intérêt est d'avoir un écosystème, et travailler avec les distros qui souhaitent aider en packageant est de mon point de vue un minimum, les distros empêchent certes quelques business model (genre package payant) mais c'est le jeu (on peut toujours vendre du "oui mais nous on est à jour" ;-) ), et donc c'est tout naturellement qu'on reprend les sources des packages créé par les distros (pour respecter les principes de chaque distro, par exemple une distro veut le numéro du .so dans le nom du paquet, pas l'autre, on a zappé la différence et ça a foutu la merde chez les utilisateurs, on n'a pas demandé au mainteneur de la distro de violer les règles de la distro mais on a fait la migration de notre paquet pas bien vers le même nom que celui de la distro) et qu'on propose nos propres patchs aux mainteneurs (il a arrive que le mainteneur n'ai pas fait le meilleur choix, faute de connaissance).
Donc au final, quand c'est fait en bonne intelligence (le développeur n'est pas un imbus de lui-même qui déteste les distros qui packagent alors qu'il veut vendre et donc accuse le libre de la gale cf histoire récente, et le packageur n'est pas un intégriste qui veut faire comme ça et pas autrement), 99% du code de package est identique entre upstream et distro, et les différences sont dues au procédures (on n'a pas les machines de Debian et Ubuntu mais OBS, quelques détails changent genre on utilise les mêmes idées que la dernière Ubuntu pour toutes les versions alors que le mainteneur Ubuntu ne touche plus au versions passées).
[^] # Re: Open build service
Posté par Adrien . Évalué à 4.
Merci pour le retour.
[^] # Re: Open build service
Posté par BAud (site web personnel) . Évalué à 1.
Pour proposer l'avis d'une distribution : utiliser OBS est un pis-aller, c'est reconnaître n'avoir trouvé personne intéressé pour packager ton logiciel, en gros tu n'as aucun relais dans la distro. Cela a quelques conséquences : ta dernière version n'est même pas disponible dans la version de dév de la distro (vu que tu as délégué et n'a rien suivi, bah c'est la vieille version qui compile qui est gardée).
OBS a soi-disant vocation à toucher RHEL/CentOS/Mageia/Suse mais en réalité, cela ne correspond en rien (les dépendances ont des noms différents, ce qui complique le packaging). C'est une perte de temps à avoir un paquet bâtard, non intégré et qui demandera du boulot au packager qui choisirait ton paquet pour supprimer tout ce que tu t'es emmerdé à faire sur OBS pour le simplifier.
Bref, autant trouver un relais dans chaque distro, avoir décrit correctement la compil' de son soft ; respecter les exigences de debian ouvre beaucoup de portes (le man, la licence… c'est lourdingue mais ça fonctionne mieux ensuite généralement).
[^] # Re: Open build service
Posté par Zenitram (site web personnel) . Évalué à 10.
Pas la faute des développeurs si les mainteneurs de distros aiment faire le taf 10x et ensuite se plaignent d'être en sous nombre.
Trouve-le moi.
ARRETEZ AVEC VOS FANTASMES.
Vous faites chier, vraiment pas d'autres mots, à balancer à chaque fois "trouvez un mainteneur". Le problème est qu'on ne trouve pas. Le problème est qu'une fois qu'on trouve on attend éternellement une validation.
CA NE MARCHE PAS.
Ou du moins pas pour tous les logiciels.Des fois oui, des fois non, c'est la roulette, et surtout ça mets des mois/années avant de trouver.
Avec Apple, par exemple, en une semaine à partir du moment où on veut mettre en ligne, c'est fait. Apple c'est l'exemple du repo à la Linux sans ses problèmes (je paye 80€/an certes, mais voila : j'ai ce dont j'ai besoin).
Alors, avant de balancer "trouvez", faite le nécessaire pour qu'on puisse trouver. Ou taisez-vous, vous vendez du rêve seulement, c'est malhonnête.
Je t'en prie, vient aider tous les projets, il y en a plein qui ont besoin d'intégration.
J'ai quelques projets qui demandent une intégration, c'est libre, prend le paquets source et mets les dans ta distro, pour me montrer qu'on peut avoir ça sans passer des heures à espérer trouver (sans garantie, c'est bien un soucis : même si je fais l'effort, je n'ai aucune garantie que je serait dans le repo, c'est un jeu de hasard, perso je ne joue pas aux jeux de hasard)
Et ça, c'est que le début (ce qui serait déjà énorme ceci-dit, comme ça on peut reprendre le source pour OBS), une fois que tu l'as mis, faut pas que ça reste figé pendant 6 mois, si une release sort il faut que cette nouvelle version soit disponible pour toutes les versions maintenues de ta distro, car utiliser une nouvelle version d'un logiciel précis ne doit pas obliger à changer de version de distro (et encore, même la dernière version de la distro a souvent une version dépassée).
Facile à dire, mais quand il faut ensuite montrer la réalité, plus personne.
Si des gens font les paquets plutôt que de "trouver un mainteneur", c'est parce qu'ils n'ont pas le choix en pratique, pas la peine de dire qu'ils peuvent faire autrement si en pratique ils ne peuvent pas (et non, attendre 6 mois d'avoir peut-être une personne qui accepte n'est pas une possibilité en pratique).
Vous pourrez répéter 1 million de fois que "pour bien faire il faut déléguer", tant que vous ne pourrez pas fournir un mainteneur pour tout projet le demandant en moins d'une semaine, vous vendez juste du rêve. Le monde bouge plus vite que ce que vous offrez, en pratique.
Sérieux, vous faites plus de mal que de bien à ne pas accepter qu'il y a un soucis.
En attendant, tu n'aimes peut-être pas OBS mais lui pense aux besoins des développeurs, en offrant un pis-aller mais vaut mieux un pis-aller que rien.
Note : je ne critique pas le principe des repos, c'est sur le principe génial et très pratique pour des projets stables, et ça fait une très bonne base, j'adore être dans les repos quand je peux, et mes utilisateurs apprécient aussi la chose quand ils n'ont pas besoin de la dernière version. Mais ensuite, quand on a besoin d'applis précises (pas "mainstream" ni "qui plait à un mainteneur, tu as du bol") en dernière version, c'est la mort et faire l'autruche sur le sujet n'améliore rien.
Note : oui, un coup de gueule, mais c'est gonflant cette réponse "trouve", justement quand le problème est qu'on ne peut pas trouver et que quand on tente, on est vite refroidi car on a bossé pour rien (le paquet attend indéfiniment en mode "need sponsor").
# Remarques
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Si il s'agit d'un logiciel libre, livrer le code source n'est pas une option. C'est le minimal à faire ! Donc quoi que tu fasses, livre au moins un tar.gz des sources.
Certes, mais dans un premier temps, ton objectif pourrait être de livrer un paquet simple, et pas de l'inclure dans les dépots officiels. Tu pourrais très bien livrer par exemple un deb qui ne respecte pas tous les prérequis de Debian. Et du coup c'est tout de suite plus simple à faire un paquet deb (même si la doc est pas évidente pour un nouveau venu). L'utilisateur aurait à télécharger manuellement le deb, et faire un dpkg -i.
L'avantage est que cela évite à l'utilisateur de compiler, mais cela peut aussi attirer les contributeurs qui voudraient améliorer le deb.
[^] # Re: Remarques
Posté par Ambroise . Évalué à 6.
Attention : il n'est pas obligé de mettre le code en Libre service pour que ça respecte la licence.
Il suffit qu'il fournisse les sources à qui lui demande il me semble.
[^] # Re: Remarques
Posté par mzf (site web personnel) . Évalué à 4.
Il y a certes des avantages pour l’utilisateur dans le fait de générer un paquet deb basique, mais je me souviens du guide pour créer des paquets de debian, avec cette remarque (diapo 42) :
Je n’aimerais pas être ce genre de personne donc autant laisser des gens spécialistes le faire, non ?
Sinon je te rassure les sources sont disponibles depuis le début: dépôt SVN accessible anonymement en lecture et miroir GitHub.
[^] # Re: Remarques
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Et ? Comme je dis, tu n'es pas obligé de suivre le guide en totalité. Tu n'es pas obligé de contribuer à Debian. L'intégration dans Debian n'est pas une obligation. Donc ton 3) n'a pas lieu d'être.
Sur mon infra, je fais des paquets debian pour installer des softs internes. Les paquets sont loin de respecter toutes les guidelines de Debian. Je fais juste le minimum pour que ça s'installe correctement sur mes serveurs. ça reste relativement simple à faire, tout en me facilitant la vie pour tout ce qui est intégration continue, déploiement automatique etc..
# Appimage
Posté par dzecniv . Évalué à 6.
Salut,
j'ai trouvé cette revue de Flatpack, Snap et Appimage très instructive: https://distrowatch.com/weekly.php?issue=20160704#opinion où il est soutenu que seul Appimage est facile à utiliser (et fonctionne tout court).
[^] # Re: Appimage
Posté par mzf (site web personnel) . Évalué à 2.
Merci pour le lien.
[^] # Re: Appimage
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
Ce sont des technologies très récentes qui n'étaient pas prêtes. Encore à ce jour, elles en sont encore à un stade de développement, mais qui commence à peine à vraiment pousser les portes des distributions.
GNOME Software par exemple a maintenant des prises en charge de ces technologies, mais cela n'est encore disponible dans aucune distribution. Ça le sera dans Fedora 25, puis va se répandre au moins dans toutes les distributions avec bureau GNOME.
KDE est aussi en train de travailler avec flatpak. Donc on veut imaginer de similaires prises en charge au cœur du bureau KDE bientôt aussi.
Les gens de Flatpak travaillent aussi sur un concept de service de distributions d'application (Flathub) mais pareil, ce n'est pas encore là.
Enfin flatpak (tout comme Snap) sont conçus par design pour être parfaitement efficaces (niveau sécurité) avec Wayland (respectivement Mir pour Snap). À ce stade, les protections du système sont encore limités par X11.
De manière générale donc, ce sont des projets naissants et il faut s'attendre à leur véritable départ auprès du grand public d'ici 6 mois voire 1 an quand les distribs auront enfin des prises en charge, commenceront les passages à Wayland, et que de plus en plus de projets proposeront des paquets upstream pour ces nouveaux systèmes.
Donc un tel texte d'opinion qui compare ces projets en plein balbutiement à AppImage n'est absolument pas justifié. Le fait est que Flatpak et Snap sont construits avec de nouveaux paradigmes, en particulier sécurité et intégration au bureau (en tout cas pour Flatpak. Je ne sais pas le travail fait sur Snap pour l'intégration au bureau). Mais y a aussi les concepts de "dépôts" (qui permettent de la mise à jour automatique, ainsi que la recherche d'application). Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Appimage
Posté par barmic . Évalué à 5.
Ça me fait assez peur, c'est quoi l'intégration au bureau en question ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Appimage
Posté par Okki (site web personnel, Mastodon) . Évalué à 4.
Les applications étant isolées, si elles souhaitent pouvoir accéder au matériel (webcam, microphone…), à la géolocalisation ou autre, l'environnement de bureau fera le lien avec l'utilisateur en lui demandant si oui ou non il souhaite autoriser telle ou telle demande. L'utilisateur doit ensuite pouvoir revenir sur sa décision s'il le souhaite.
[^] # Re: Appimage
Posté par barmic . Évalué à 6.
Ouai… J'espère qu'ils ont aussi bossé le découplage parce que je vais pas me mettre à utiliser un bureau juste pour ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Appimage
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Ben les trucs classiques: fichiers appdata, desktop, icône… Ce sont des détails, pourtant importants pour le confort d'utilisation au jour le jour.
En gros, le bureau a accès aux informations du logiciel. Ainsi:
Si le bureau a encore un menu avec des catégories, avec GIMP installé par flatpak, l'utilisateur pourra trouver GIMP dans son menu, sous la catégorie "Graphisme".
Si le bureau a un champs de recherche pour trouver les programmes (par exemple comme dans GNOME), taper "gimp" propose GIMP, mais aussi si je tape "photo", "dessin", "graphisme", "image" ou autres mots clés similaires. Éventuellement une courte description du logiciel sera aussi disponible.
L'icône officielle de GIMP sera associée au logiciel (dans menu ou par recherche…) et éventuellement à des fichiers (s'il n'y a pas une prévisualisation plus adaptée).
Les fichiers XCF (et éventuellement d'autres formats d'image) seront liés à GIMP par défaut: double-cliquer un fichier XCF ouvrira GIMP.
GIMP sera proposé comme logiciel alternatif pour d'autres formats qui sont pris en charge mais pour lesquels GIMP n'est pas forcément le meilleur défaut (par exemple, un jpeg, je préfère avoir un simple visionneur par défaut, mais clic droit > "Ouvrir avec une autre application" me proposera GIMP en tête).
Bien qu'installé par flatpak, et non par le gestionnaire de paquet habituel, je peux quand même voir GIMP dans mon gestionnaire de logiciel (avec sa description et des captures d'écran), le désinstaller et même le mettre à jour.
En gros, toutes ces différentes interactions avec le système rendent l'installation par flatpak transparente. Un système "un clic" sans aucune forme d'interaction avec le système, bien qu'attrayant au premier abords, si cela ne permet pas une utilisation intégrée au système, l'intérêt est fortement réduit pour utilisation quotidienne: je me vois pas devoir aller dans un répertoire quelconque, chercher une icône AppImage (ou autre format similaire) à double-cliquer pour lancer le logiciel à chaque fois que j'en ai besoin (alors que j'aurais pu passer par le mode de lancement habituel du bureau ou simplement double-cliquer mon image xcf).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Appimage
Posté par saltimbanque (site web personnel) . Évalué à 5.
Hallu?
La conception même de flatpack serait mauvaise car trop d'étapes sont nécessaires à l'utilisateur? L'auteur feint d'ignorer que ce n'était qu'un premier stade. Ces temps ci l'expression broken by design sert surtout aux imbéciles à se faire mousser, alors qu'ils ne parlent justement pas de la conception d'un truc mais seulement de la partie visible de l'iceberg… Article -> poubelle, pas étonnant vu le site.
# Sources signées
Posté par Ellendhel (site web personnel) . Évalué à 4.
J'abonde dans le même sens pour ce qui est de la diffusion des fichiers sources (archive contenant le code plus les differents fichiers tel que README, INSTALL, …).
Un point qui est aussi appréciable est d'avoir un moyen de vérifier l'intégrité des fichiers : à minima donner les sommes de contrôle MD5/SHA1/SHA2 sur le site web, et dans l'idéal proposer un fichier de signature cryptographique (.asc). Cela demande évidemment un peu plus de travail initial (créer et diffuser la clé GPG, ajouter une étape de signature après avoir crée l'archive de fichiers sources) mais c'est appréciable de pouvoir vérifier que rien n'ait été modifié, surtout si ton logiciel se retrouve diffusé en différent endroits.
[^] # Re: Sources signées
Posté par mzf (site web personnel) . Évalué à 2.
Je diffuse déjà les sommes de contrôle MD5 et SHA1.
Ça me paraissait être juste un délire de geek parano, mais tu as raison cela peut aider les créateurs de paquets !
[^] # Re: Sources signées
Posté par gouttegd . Évalué à 6.
L’intérêt des sources signées, c’est que ça permet au moins de vérifier que la release n provient bien de la même personne que la release n−1 (puisqu’elle est signée avec la même clef).
Certes, je ne peux pas pour autant vérifier que ces releases viennent bien de toi (à moins d’avoir pu vérifier ta clef via un canal séparé, comme la toile de confiance), mais rien qu’avoir l’assurance que c’est bien le même développeur derrière chaque release est déjà appréciable (et à vrai dire ça me paraît plus important que de savoir qui est ce développeur et est-ce qu’il s’appelle vraiment François Mazen).
# Will it work ?
Posté par ɹǝıʌıʃO . Évalué à 10.
Tellement vrai…
[^] # Re: Will it work ?
Posté par saltimbanque (site web personnel) . Évalué à 6.
Voilà y'a plus qu'à voir où se situe flatpack dedans.
# Faciliter le travail des empaqueteurs
Posté par niol (site web personnel) . Évalué à 10.
Des trucs tout bêtes pour faciliter le travail des empaqueteurs des distributions :
Le respect de ces règles simples simplifie énormément le travail de négociation ou d'archéologie que doit faire l'empaqueteur, très chronophage.
[^] # Re: Faciliter le travail des empaqueteurs
Posté par mzf (site web personnel) . Évalué à 2.
Merci pour ces conseils !
[^] # Re: Faciliter le travail des empaqueteurs
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
Il faut également penser à fournir des fichiers Desktop et AppData.
# Flatpak, Snappy, AppImage
Posté par Sébastien Wilmet . Évalué à 3. Dernière modification le 08 octobre 2016 à 20:47.
Ton application utilise Qt, mais le runtime Flatpak pour Qt/KDE est toujours en développement. Flatpak a pour l'instant un meilleur support pour GTK+/GNOME (puisque Flatpak est principalement développé par des développeurs GNOME).
Donc, pour l'instant je conseillerais AppImage pour une application Qt (même si j'ai jamais essayé moi-même, il parait que ça fonctionne bien).
AppImage s'occupe uniquement de l'empaquetage/installation. Flatpak et Snappy vont plus loin pour isoler les applications dans une sandbox.
Entre Flapak et Snappy, j'ai tendance à préférer Flatpak. Lire cet article par exemple.
[^] # Re: Flatpak, Snappy, AppImage
Posté par mzf (site web personnel) . Évalué à 2.
Merci pour ces informations !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.