Notices by Patrice Ferlet aka MΣƬΛᄂ3D (metal3d@techlover.eu), page 2

Bah... c'est un peu normal qu'un projet, réfléchis par ceux qui le font, aient une bonne idée de comment on doit installer une app.

Par exemple la fondation Apache, elle le sait qu'elle propose plusieurs services (httpd, tomcat, etc...) - Il me parait évident de suivre leur reco en ayant un utilisateur "apache" et des confs placés dans le respect de leurs call.

Pourquoi Debian parle de "apache2" ?

@dada @lanodan @breizh

donc Debian est un souci

@breizh @dada @lanodan

Ce n'est pas une question de comment le monde tourne. C'est une question très intéressante de savoir les raisons qui poussent les gens à utiliser une distrib qui ne respecte pas les standard FHS, XDG, etc. Alors que 99% des autres font cet effort justifié.

On en arrive à des failles béantes créées par des patcheur Deb, à répétition, et tout le monde continue à y aller tête baissé.

Debian fait ce qu'il veut, mais ils n'ont pas raison de le faire.

@breizh @dada @lanodan

Après, que tu estimes que c'est à la communauté Debian de packager la terre entière à sa sauce pour que tu puisses l'installer "à leur manière" et que tu ne te plains pas des failles c'est une autre histoire.

Moi j'ai posé une question simple: pourquoi choisir Debian "par défaut". Personne n'y répond depuis tout à l'heure, du mois, personne ne me donne d'argument valide qiu prime sur les autres distros

@breizh @dada @lanodan

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

@lanodan @dada @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

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

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

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

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

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

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

@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

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

@lanodan @dada @breizh

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

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

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

Si tu veux des exemples:
https://github.com/nginxinc/docker-nginx/issues/171

Si tu cherches "docker nginx issue site-available" tu vas voir le bordel que ça crée.

C'est une idée absurde, surtout qu'on leur dit depuis des années (à Debian) que faire un simple lien symbolique entre "sites-available" et "conf.d" pourrait déjà corriger un paquet de problèmes. Mais ils s'en tamponnent (position dominante)

@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

@dada deux choix qui me rendent malade...
Je n'ai jamais compris cet engouement pour les distriq debian like. Rien que la construction non vérifiée de paquets est problématique.

Un jour faudra que quelqu'un essaye de me démontrer en quoi ces deux distros sont au dessus de Fedora (serveur ou desktop)