Par exemple; on pourrait imaginer qu'un projet ait son propre dépot deb. Ainsi c'est à jour, avec un packaging bien fait tu gère tout à fait les différentes versions, c'est très très simple à inclure dans les distribution après.
On peut imaginer pleins de choses. Mais les deb ça marche sur Debian et dérivé uniquement (et encore modulo quelques incompatibilités) plus RH&Fed avec alien. Là on parle de choses qui sont utilisé sur n'importe quelle distribution linux, sur XP/Vista/Seven/8, sur OS X et sur les BSD évidement. Ça fait une dizaine d'années que rpm est le standard LSB et assez peu de distribution en définitive s'en servent. Bref faut quand même pas mal d'imagination pour imaginer créer un dépôt deb et l'utiliser partout. Même si demain apt deviens utilisable et utilisé sur toutes les plateformes tu aura toujours un tas de problème :
système wide
pas de possibilité simple universel pour avoir n version d'une même bibliothèque
La question de la portabilité n'a pas de sens : Au lieu de développer un truc genre gem pour toutes les plate-formes, on pourrait imaginer intégrer un truc genre dpkg ou rpm dans le langage en question, à première vue ça ne semble pas beaucoup plus difficile.
Ça veut dire quoi « intégrer un truc genre dpkg ou rpm dans le langage en question » ? C'est un vrai question.
Au final je pense que c'est vraiment une quetsion de vision : le gestionnaire de paquet pense toute la chaine de distribution, ce qui peut être contraignant. Les gestionnaires genre gems ne pensent qu'à l'aspect "je balance mon truc vite fait". Evidemment ça va plus vite, mais bon c'est l'arrache totale.
Je ne les connais pas tous, mais pour CPAN tu a une panoplie de test (exemple avec Mosse). Maven possède une gestion précise des releases assez contraignante mais conçu pour rendre le build aussi reproductible que possible. Je ne doute pas que les autres ont aussi leur critère dans leur coin.
Mais note que c'est nécessaire de pouvoir balancer ton truc vite fait sur ton dépôt à toi, pour pouvoir le partager avec ceux qui veulent développer leur logiciel sur la prochaine version de ta bibliothèque par exemple.
Bref c'est plus qu'une question de vision c'est une question de besoin. dpkg/rpm ne répondent pas à ces besoins entre autre car :
ils ne permettent pas simplement la cohabitation de plusieurs versions
ils sont au niveau système :
installer une bibliothèque à tendance à impacter l'ensemble du système
il faut être root de la machine pour s'en servir
ils sont liés à quelques systèmes d'exploitation et non pas à tous (Win, OSX et BSD compris)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par barmic . En réponse à la dépêche La bibliothèque SDL est sortie en version 2.0. Évalué à 5.
On peut imaginer pleins de choses. Mais les deb ça marche sur Debian et dérivé uniquement (et encore modulo quelques incompatibilités) plus RH&Fed avec alien. Là on parle de choses qui sont utilisé sur n'importe quelle distribution linux, sur XP/Vista/Seven/8, sur OS X et sur les BSD évidement. Ça fait une dizaine d'années que rpm est le standard LSB et assez peu de distribution en définitive s'en servent. Bref faut quand même pas mal d'imagination pour imaginer créer un dépôt deb et l'utiliser partout. Même si demain apt deviens utilisable et utilisé sur toutes les plateformes tu aura toujours un tas de problème :
Ça veut dire quoi « intégrer un truc genre dpkg ou rpm dans le langage en question » ? C'est un vrai question.
Je ne les connais pas tous, mais pour CPAN tu a une panoplie de test (exemple avec Mosse). Maven possède une gestion précise des releases assez contraignante mais conçu pour rendre le build aussi reproductible que possible. Je ne doute pas que les autres ont aussi leur critère dans leur coin.
Mais note que c'est nécessaire de pouvoir balancer ton truc vite fait sur ton dépôt à toi, pour pouvoir le partager avec ceux qui veulent développer leur logiciel sur la prochaine version de ta bibliothèque par exemple.
Bref c'est plus qu'une question de vision c'est une question de besoin. dpkg/rpm ne répondent pas à ces besoins entre autre car :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)