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

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

On se lit à une distribution pour des raisons pratiques:

- avoir une image de base et pas 20, pour limiter le poids de ta base images
- avoir des versions de lib communes ou imposées par un client (genre, la libssl)
- avoir du support sur des paquets en dépendance

La distro compte

@breizh

Alors justement c'est pas la question.

Si tu normalises, tu dois pouvoir compiler et installer sur Arch, et le même script, ou presque, doit passer sur les autres distro. La seule différence va venir des install de package de dependances.

Or, comme je te le dis, si tu pars du principe que "sites-enabled" est un truc standard, alors tout pète sur les autres distros.

Debian donne des mauvaises habitudes, vraiment

@breizh @dada

Non, justement.

Quand tu package Nginx sur un conteneur, tu ne prends surtout pas les paquets de la distribution (qui implique des deps, des prefs, etc...)

Tu compiles et installes.

Or, si ta base d'automatisation part de Debian, tu as des soucis de compat sur 99% des autres distros. Or, Debian est utilisé de-facto (de moins en moins) - donc ça pose problème

@breizh @dada

Il est absolment normal que le mainteneur d'une solution se charge des distros.

Tu ne peux pas demander à un spécialiste Debian de packager 300 applications sur Docker.

Tu peux par contre demander à un spécialiste Nginx de packager pour 4 ou 5 distrso "demandées"

@breizh @dada

Je ne te dis pas que Debian influe sur les autres distros. Je te dis qu'ils influent sur le travail des packageurs (que ce soit Docker ou pas)

Casser des standards, des normes, ne pas respecter la paroles des éditeurs de solutions (apache est un exemple parmis des centaines), c'est un "problème"

@breizh @dada

alors si, y'a la FHS: https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

C'est un exemple parmi plein de standard.

Quant à ta remarque sur les mainteneurs Docker, tu imagines que tu demande un nombre exponentiel de mainteneurs ?

@breizh @dada

Et je ne te parle pas des délires avec le compte "apache" qui devient "www-data", et qu'ils ont appelé "httpd" => apache...

Apache n'est pas un serveur, ils n'arrivent pas à l'admettrre. Apache propose httpd et tomcat.

Foutre un utilisateur commun entre nginx, tomcat et httpd c'est délirant...

Bref, ils font un peu n'imp. On s'en sort hein, mais ils nous complique la tâche 🙂

@breizh @dada

je voulais dire "enabled", pardon

@breizh @dada

Tu bottes en touche. Le souci est réel. Les mainteneurs sont les gens de Docker, ils automatisent un pauquet de chose.

Or, des règles spécifique de Debian mettent à mal la symbiose des conf. C'est bien de la faute de Debian là.

@breizh @dada