Je ne le crois pas. La majorité des projets sont globalement la même chose, je ne crois pas qu'il soit nécessaire de lancer doom dans son système de build. Réinventer un build pour chaque bibliothèque est un échec d'ingénieure.
La majorité, oui, mais je pense que tôt ou tard, tu va tomber sur un cas non géré, et la question de comment gérer ça se pose. Par exemple, si tu veux rajouter le support d'un nouvel outil pour transformer la doc. À partir de la, soit tu as tout dans le core de ton outil (et ça explose de complexité), soit tu as des plugins. Et si tu as des plugins, alors tu ouvres la porte à des dérives (comme tu dit, M4 peut muter le systeme de build, mais c'est le but, sinon ton systéme de build est figé et ça pose d'autres soucis).
Bien sur, tu peux aussi dire merde, mais en général, tu n'es pas populaire quand tu fait ça.
Je pense qu'un bon DSL serait mieux que du shell a tout bout de champ, mais on a des tonnes d'outils de build dans le logiciel libre, et on tombe toujours dans les mêmes travers, donc peut être qu'il faut se demander pourquoi.
C'est vrai, je ne sais pas à quel point c'est utilisé dans debian, la plupart des paquets ne devraient pas en avoir besoin du tout (dès maintenant) et pour les autres cartographier les cas (ajout de modules dans le noyau, ajout d'une police,...) pourrait réduire à peau de chagrin les cas où c'est utile.
Debian ne me parait pas le bon exemple, vu que la communauté à tendance à parfois chercher à corriger des fichiers de configs, etc. Sur un serveur que j'ai depuis longtemps, je compte 716 scripts:
$ ls /var/lib/dpkg/info/*.post* | wc -l
716
Je sais que des gens de Fedora ont bossé pour convertir beaucoup de script à des trucs automatiques (les fameux file triggers), pour par exemple lancer ldconfig quand tu installes une lib, faire ce qu'il faut avec systemd quand tu installes un service, etc.
Et je pense que dpkg supporte ça aussi, mais j'ai plus fait de paquet rpm et debian depuis longtemps.
Et aussi longtemps qu'on voudra avoir des upgrades de paquets sans perte de données, on va devoir utiliser des scripts (exemple, upgrade de postgresql).
Ensuite, si un jour, on veut passer à des déploiements via des images ostree et/ou des conteneurs, il va bien falloir se débarrasser des scripts en question, car ça ne rentre pas dans le workflow.
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 3.
La majorité, oui, mais je pense que tôt ou tard, tu va tomber sur un cas non géré, et la question de comment gérer ça se pose. Par exemple, si tu veux rajouter le support d'un nouvel outil pour transformer la doc. À partir de la, soit tu as tout dans le core de ton outil (et ça explose de complexité), soit tu as des plugins. Et si tu as des plugins, alors tu ouvres la porte à des dérives (comme tu dit, M4 peut muter le systeme de build, mais c'est le but, sinon ton systéme de build est figé et ça pose d'autres soucis).
Bien sur, tu peux aussi dire merde, mais en général, tu n'es pas populaire quand tu fait ça.
Je pense qu'un bon DSL serait mieux que du shell a tout bout de champ, mais on a des tonnes d'outils de build dans le logiciel libre, et on tombe toujours dans les mêmes travers, donc peut être qu'il faut se demander pourquoi.
Debian ne me parait pas le bon exemple, vu que la communauté à tendance à parfois chercher à corriger des fichiers de configs, etc. Sur un serveur que j'ai depuis longtemps, je compte 716 scripts:
Je sais que des gens de Fedora ont bossé pour convertir beaucoup de script à des trucs automatiques (les fameux file triggers), pour par exemple lancer ldconfig quand tu installes une lib, faire ce qu'il faut avec systemd quand tu installes un service, etc.
Et je pense que dpkg supporte ça aussi, mais j'ai plus fait de paquet rpm et debian depuis longtemps.
Et aussi longtemps qu'on voudra avoir des upgrades de paquets sans perte de données, on va devoir utiliser des scripts (exemple, upgrade de postgresql).
Ensuite, si un jour, on veut passer à des déploiements via des images ostree et/ou des conteneurs, il va bien falloir se débarrasser des scripts en question, car ça ne rentre pas dans le workflow.