Potentiellement ces outils d'installation propres à chaque langage devraient être capable de produire directement un paquet pour chaque distribution, qui un deb, qui un rpm, etc. Il suffirait qu'un ou quelques courageux s'y colle! (Comme toujours, vous me direz!)
Oui, le problème conceptuel étant la séparation entre packaging et code. Si tu avais lu les liens du post avant, tu aurais vu que le problème réside dans le fait que "gems" est intrusif (les gens utilisent l'api gem directement dans le code) ce qui fait que le code en question ne peut plus être installé indépendamment de gems. Comme je le disais, le même problème s'est posé avec setuptools. Sans cela, pas besoin de gems, donc pas de problèmes de packaging.
L'autre problème qui fait qu'un paquet debian (ou redhat, ou arch, ou n'importe quelle autre distro) ne peut pas fournir directement un fichier gem est que les gestionnaires de paquets des distributions sont faits spécifiquement pour éviter l'installation de plusieurs versions mineures successives de la même lib car cela ne sert à rien et est contre-productif. À l'opposé, les gems obligent à l'installation de versions mineures différentes dans des dossiers différents, en fonction de ce qui est demandé par les applications.
(bon, à strictement parler, on pourrait s'amuser à travailler comme pour le noyau linux avec des paquets libfoo-ruby-2.2.3, libfoo-ruby-2.2.6, etc, mais avouez quand même que sailamert)
[^] # Re: Des Gems pour la bibliothèques standard?
Posté par nud . En réponse à la dépêche Petites brèves : Ruby 2.0, DataMapper et RubyLive. Évalué à 2.
Oui, le problème conceptuel étant la séparation entre packaging et code. Si tu avais lu les liens du post avant, tu aurais vu que le problème réside dans le fait que "gems" est intrusif (les gens utilisent l'api gem directement dans le code) ce qui fait que le code en question ne peut plus être installé indépendamment de gems. Comme je le disais, le même problème s'est posé avec setuptools. Sans cela, pas besoin de gems, donc pas de problèmes de packaging.
L'autre problème qui fait qu'un paquet debian (ou redhat, ou arch, ou n'importe quelle autre distro) ne peut pas fournir directement un fichier gem est que les gestionnaires de paquets des distributions sont faits spécifiquement pour éviter l'installation de plusieurs versions mineures successives de la même lib car cela ne sert à rien et est contre-productif. À l'opposé, les gems obligent à l'installation de versions mineures différentes dans des dossiers différents, en fonction de ce qui est demandé par les applications.
(bon, à strictement parler, on pourrait s'amuser à travailler comme pour le noyau linux avec des paquets libfoo-ruby-2.2.3, libfoo-ruby-2.2.6, etc, mais avouez quand même que sailamert)