utilisation d'une version de XulRunner plus récente que celle proposée par le paquet officiel de la distrib. Et si l'appli a besoin d'une version plus récente, c'est bien souvent pour profiter des dernières API de Gecko etc..
La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne. Sinon, autant packager tout en statique et on évite du même coup les différences de version des autres paquets.
utilisation d'une version patchée de XulRunner ou buildée différement.
C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier. Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins. Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.
Pour moi, le fait que tout le monde utilise sa propre version patchée de xulrunner exhibe juste un problème dans la maintenance de xulrunner lui-même, probablement parce que Mozilla n'est pas intéressé à maintenir celui-ci comme une lib classique (ceci a déjà été vu avec les histoires autours de mozembed par exemple)
Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment.
Idem, si Debian package une application, ils se débrouillent pour que les dépendances soient à jour. Cela fonctionne pour tous les autres programmes.
Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.
Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.
Reposer sur des versions patchées des libs n'est jamais une bonne idée.
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 10.
La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne. Sinon, autant packager tout en statique et on évite du même coup les différences de version des autres paquets.
C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier. Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins. Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.
Pour moi, le fait que tout le monde utilise sa propre version patchée de xulrunner exhibe juste un problème dans la maintenance de xulrunner lui-même, probablement parce que Mozilla n'est pas intéressé à maintenir celui-ci comme une lib classique (ceci a déjà été vu avec les histoires autours de mozembed par exemple)
Idem, si Debian package une application, ils se débrouillent pour que les dépendances soient à jour. Cela fonctionne pour tous les autres programmes.
Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.
Reposer sur des versions patchées des libs n'est jamais une bonne idée.