Patrice Ferlet aka MΣƬΛᄂ3D @metal3d@techlover.eu

Tu te rends compte que beaucoup d'application n'ont pas de packageur ? Que c'est un boulot bélévol pour 99% des packageurs ? Qu'ils sont souvent responsabilisé à tort d'un déploiement d'une app qu'ils n'ont jamais dév ?

Et tu sais combien de temps il faut pour voir une app arriver en upstream sur les dépots officielles dune distro ?

Tu sais qu'on installe rarement les paquets d'une distro en prod ? (et que c'est même pas recommandé en fait ?)

@breizh

Alors il faura répondre à ma toute première question 🙂

@breizh

Il ont des serveur RH parce qu'ils ont du support.

On teste sur Rocky, tout va bien. Sur Arch, pareil, sur Alpine idem...

Il veulent des tests sur Deb/like parce que leur produit va bien entendu devoir s'installer sur ces distros

Donc, non, ce n'est pas con du tout
@breizh

Alors en soit, si Debian faisait ne serait-ce que deux ou trois changements qui n'a pas vraiment d'impacts profond, ça serait top. Genre le link site-enabled => conf.d tu n'imagines pas comme ça soulagerait.

Ce qui pose vraiment problème, c'est leur manque d'écoute de la commu. Dans un monde Linuxien où justement la commu est importante... c'est un comble à mes yeux

@breizh

Tu réduis trop le problème. Je ne connais pas ton job, mais dans le miens c'est beaucoup plus compliqué d'aller dire à nos clients que nous voulons telle ou telle distro.

Et tu n'imagines pas à quel point certains deploiements sont complexe malgré des mois de boulot à les réduire.

On parle d'appli ayant parfois plus de 200 points de connexion hein

@breizh

Mais... justement c'est bien la distro qui pose problème là.

Aucune autre ne fait ça...

Ou du moins, le souci c'est que trop de gens prennent Debian par défaut sans prendre conscience qu'elle ne respecte pas la FHS, ni XDG, ni les reco des éditeurs comme Apache, etc.

@breizh

Tu veux appeler mon client et lui expliquer ? Genre qu'il ne pourra pas proposer son app sur Github avec un package automatisé, et que son application ne sera testé que sur Ubuntu ?

@breizh

"allo Microsoft, ouais c'est moi... bouge ton cul et mets des Red Hat sur GitHub"

@breizh

Y'a pas que des install à faire, on bosse sur des tests, des check d'install, des vérifications de sécu.

Quand tu dois passer par 3 ou 4 distros et que la seule qui te demande de tout changer est Debian, tu dois admettre qu'elle a un souci
@breizh

Je peux te donner un exempe tout con pour, potentiellement, que tu comprennes où je pense que tu te plantes.

On a fait un dev avec des pipelines de tests. Sur du GtilabCI, en mode "runner ssh". Les machines du clients sont en RH. Script avec les conf "standards des éditeurs"

Il nous a demandé de juste passer les pipelines sur Github... qui utilise ubuntu...

Tout a explosé... des jours de boulots à cause de noms de comptes et de répertoires non standards

@breizh

Donc tu pars du principe que pour installer mon programme, il faut qu'un mainteneur Debian fasse un paquet

Déjà, là, on est pas du tout d'accrord

@breizh

Justement non, en ce qui concerne la conteneurisation, on n'utilise ni systemd ni openrc - on utilise le mode "standard"

@lanodan @dada @breizh

Donc, selon toi, y'a 40 distros possibles, je dois faire 40 options dans le makefile ?

C'est étonnant que nos Makefiles ne fasses que "if debian, else" non ?

Tu ne vois pas que c'est la seule qui pose souci ?

@breizh

Oui elle peut, mais ça ne lui donne pas raison !

Et on a pas toujours le choix, coté pro, de la distro qui sera imposée.

Quand tu dois conteneuriser, Debian pose systématiquement un souci du moment où tu commences à faire des choses un peu plus poussées qu'un "apt install"

@breizh

Non, un make install doit être fait par le dev ou le devops

Moi je fais en sorte que ça passe partout. Et je me bats tous les jours avec Debian

@breizh

Docker: je fais un Dockerfile avec un truc standardisé => ça compile partout sauf sur Deb/Like

Ansible, pareil, obligé d'avoir un detecteur "Debian" pour corriger des install

Debian est le seul qui nous impose d'être détecté pour faire "à leur manière". Donc je suis désolé mais c'est bien Debian qui pose problème. C'est le 1% qui a tort 😜

@lanodan @dada @breizh

Ce que beaucoup n'arrive pas à comprendre c'est que ce souci n'est induit que par une seule distrib: Debian. C'est la seule qui casse autant les standards.

Arch, Rocky, RH, Gentoo, alpine, etc... ne posent pas ces problèmes

@breizh

La création de package est un autre problème

@lanodan @dada @breizh

Sauf que c'est le mode standard de Debian...

Et que quand un dev me donne un makefile qui utilises "site-enabled", je suis cramé pour l'install sur une RH.

Et si je modifie le script, pour utiliser conf.d, alors ça ne va pas marcher sur Debian. Debian est le seul à faire ça.

@breizh

Je suis désolé mais je pense que tu as un biais d'utilisation.

Je prend un exemple: je code une app, je propose un truc qui ne marche que sur Fedora (pour faire chier le monde) - tu attends quoi ? que Debian fournisse un paquet modifié, ou que je fasse mon job et que je propose un mode d'install qui fonctionne partout ?

@breizh @dada