Le monde du packaging est oui, en effet, le bordel. Mais ce n'est pas sans raisons...
Chaque package système a été crée pour résoudre un ou des problématiques précises, et souvent contradictoires.
RPM ou Deb sont clairement orienté "sys admin", ils ont été désigné pour le système et par le système :
- Ils compilent depuis les sources
- Autorisent l'ajout de "patch" home made pour gérer ton infrastructure, la recompilation meme du kernel lui meme...
- Supportent une résolution des dépendances complexes et sont fait pour des updates "smooth"
- Mettent un accent important sur la sécurité signature
- Integrent des choses comme
- le support de la documentation
- la gestion des symbols de debuggage
- la separation des headers / libs
Mais d'un autre coté :
- Ils demandent un apprentissage et un effort conséquent
- Ils sont peu ou pas du tout adaptés a la gestion des versions multiples
- Ils nécessitent les droits roots
- Ils ne sont pas fait pour du packaging quick & dirty ( deploiement de binaires )
Pour toute ces raisons, on a vu l’émergence de système packaging orienté "développeur" bien plus "quick & dirty" et souvent langage spécifique pour une meilleur intégration avec l’environnent de développement :
pip pour python, gem pour Ruby, cargo pour rust, mvn pour Java, npm pour node, cabal pour haskell, cpan pour perl, go get pour go .... Et j'en oublie....
L'avantage de ça, c'est que si ils sont en effet très "pratique" pour du développement et du déploiement rapide... car sont très bien intégrés avec leur langage respectif et demande un effort minimal pour packager une nouvelle app existante..
Le problème de ça c'est que ce sont bien souvent des cauchemars à administrer qui risque très certainement de causer plusieurs crises d’épilepsie a votre pauvre sysadmin.
Ils sont difficile à tracer car souvent installer en home-env
Certains ont une sécurité souvent douteuse (...pip)
Ils s’intègrent pas ou peu avec des softs en code natifs ou dans un langage concurrent
Le versionning est souvent partiel, ou même incomplet
ils necessitent tous leur propre repository.... souvent sous control externe.
La reproducibilité est souvent une catastrophe.
Maintenant qui blamer dans l'histoire ? Le sysadmin conservateur ou le developpeur avant-gardiste ?
Je dirai, aucun des deux. Chacun a ses cas d'utilisations et de très bonnes raisons de faire ce qu'il fait.
Ce qu'il faudrait c'est avant tout un peu de compréhension mutuel qui aiderait a ce que :
1- le developpeur comprenne que non, deployer un tool obscure à coup de pip en production n'est pas acceptable
2 - le sys admin comprenne que oui, utiliser un compilateur ou un package vieux datant de la premiere guerre mondiale, est souvent une grosse source d'emmerdes.
Et la solution sur le long terme pourrait venir de packaging système "hybride" comme Nix (http://nixos.org/) qui essaient de conjuguer le "moins-pire" des deux mondes.
# A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Le monde du packaging est oui, en effet, le bordel. Mais ce n'est pas sans raisons...
Chaque package système a été crée pour résoudre un ou des problématiques précises, et souvent contradictoires.
RPM ou Deb sont clairement orienté "sys admin", ils ont été désigné pour le système et par le système :
- Ils compilent depuis les sources
- Autorisent l'ajout de "patch" home made pour gérer ton infrastructure, la recompilation meme du kernel lui meme...
- Supportent une résolution des dépendances complexes et sont fait pour des updates "smooth"
- Mettent un accent important sur la sécurité signature
- Integrent des choses comme
- le support de la documentation
- la gestion des symbols de debuggage
- la separation des headers / libs
Mais d'un autre coté :
- Ils demandent un apprentissage et un effort conséquent
- Ils sont peu ou pas du tout adaptés a la gestion des versions multiples
- Ils nécessitent les droits roots
- Ils ne sont pas fait pour du packaging quick & dirty ( deploiement de binaires )
Pour toute ces raisons, on a vu l’émergence de système packaging orienté "développeur" bien plus "quick & dirty" et souvent langage spécifique pour une meilleur intégration avec l’environnent de développement :
pip pour python, gem pour Ruby, cargo pour rust, mvn pour Java, npm pour node, cabal pour haskell, cpan pour perl, go get pour go .... Et j'en oublie....
L'avantage de ça, c'est que si ils sont en effet très "pratique" pour du développement et du déploiement rapide... car sont très bien intégrés avec leur langage respectif et demande un effort minimal pour packager une nouvelle app existante..
Le problème de ça c'est que ce sont bien souvent des cauchemars à administrer qui risque très certainement de causer plusieurs crises d’épilepsie a votre pauvre sysadmin.
Maintenant qui blamer dans l'histoire ? Le sysadmin conservateur ou le developpeur avant-gardiste ?
Je dirai, aucun des deux. Chacun a ses cas d'utilisations et de très bonnes raisons de faire ce qu'il fait.
Ce qu'il faudrait c'est avant tout un peu de compréhension mutuel qui aiderait a ce que :
1- le developpeur comprenne que non, deployer un tool obscure à coup de pip en production n'est pas acceptable
2 - le sys admin comprenne que oui, utiliser un compilateur ou un package vieux datant de la premiere guerre mondiale, est souvent une grosse source d'emmerdes.
Et la solution sur le long terme pourrait venir de packaging système "hybride" comme Nix (http://nixos.org/) qui essaient de conjuguer le "moins-pire" des deux mondes.