je sais que mon logiciel est packageable. Je sais par exemple que le make install installe bien la doc, ou ce genre de choses.
Si un utilisateur veut un rpm de la dernière version, ben il est là. Alors oui, ça marche que pour fedora, parce que c’est ce que je sais faire (et oui, un utilisateur m’a déjà « réclamé » un package, parce qu’il avait la flemme de faire « cmake . » et d’installer les dépendances lui-même)
Quand je voudrai soumettre le paquet, officiellement, à fedora, ben ça sera déjà fait, et je saurai quand un de mes commits casse mon paquet.
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.
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).
Less is more, comme dit. Tu imagines si tu maintiens 50 distributions dans ton dépôt ? J'ose pas imaginer le bordel.
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.
Alors qu'au départ, si tu délègues complètement cette tâche, tu n'as aucun souci.
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 louiz’ (site web personnel) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. É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.