Cette merde est bien utile je trouve.
Qui parle de dev mac ? Quand je prends libpurple utilisée dans les softs
d'IM, elle n'est pas développée sur mac à la base.
Oui c'est ça avoir le choix. Soit tu prends le binaires et tu fais
confiance au dev de fournir un truc qui fonctionne. Soit tu prends les
sources et tu compiles toi-même. Un peu comme sous linux quoi :-)
Cette merde est bien utile je trouve.
Qui parle de dev mac ? Quand je prends libpurple utilisée dans les softs
d'IM, elle n'est pas développée sur mac à la base.
Oui c'est ça avoir le choix. Soit tu prends le binaires et tu fais
confiance au dev de fournir un truc qui fonctionne. Soit tu prends les
sources et tu compiles toi-même. Un peu comme sous linux quoi :-)
Cette merde est bien utile je trouve.
Qui parle de dev mac ? Quand je prends libpurple utilisée dans les softs
d'IM, elle n'est pas développée sur mac à la base.
Oui c'est ça avoir le choix. Soit tu prends le binaires et tu fais
confiance au dev de fournir un truc qui fonctionne. Soit tu prends les
sources et tu compiles toi-même. Un peu comme sous linux quoi :-)
JEf wrote in message:Cette merde est bien utile je trouve.
À la lumière du reste de tes vues sur l'informatique, ça me confirme dans
mon opinion.Qui parle de dev mac ? Quand je prends libpurple utilisée dans les softs
d'IM, elle n'est pas développée sur mac à la base.
Quoi la libpurple ?
Oui c'est ça avoir le choix. Soit tu prends le binaires et tu fais
confiance au dev de fournir un truc qui fonctionne. Soit tu prends les
sources et tu compiles toi-même. Un peu comme sous linux quoi :-)
Non, sous Linux, on fait confiance aux développeurs pour fournir les sources
d'un logiciel intéressant, et aux packageurs pour en faire un truc qui
marche, maintenu sur le long terme et mis à jour de manière cohérente. Deux
boulots différents, avec des enjeux bien séparés.
Je prends un exemple simple : une bibliothèque pour un protocole réseau, et
quatre ou cinq applications d'origines diverses qui l'utilisent. Un bug de
sécurité est découvert dans la bibliothèques ; les développeurs de la
bibliothèque publient immédiatement une version corrigée, totalement
compatible avec l'ancienne.
Tu veux compter sur le fait que tous les groupes qui ont publié une
application utilisant cette bibliothèque vont (1) suivre les alertes de
sécurité et (2) avoir une infrastructure de mises à jour impératives ? Même
si c'est le cas, c'est du gaspillage d'efforts considérable de refaire
plusieurs fois la même chose ainsi. Et en pratique, plus de la moitié
n'auront pas fait cet effort, et tu te retrouveras avec des applications
trouées sur ton système.
JEf wrote in message<KPedndHFYKI9uvzRnZ2dnUVZ8nSdnZ2d@giganews.com>:
Cette merde est bien utile je trouve.
À la lumière du reste de tes vues sur l'informatique, ça me confirme dans
mon opinion.
Qui parle de dev mac ? Quand je prends libpurple utilisée dans les softs
d'IM, elle n'est pas développée sur mac à la base.
Quoi la libpurple ?
Oui c'est ça avoir le choix. Soit tu prends le binaires et tu fais
confiance au dev de fournir un truc qui fonctionne. Soit tu prends les
sources et tu compiles toi-même. Un peu comme sous linux quoi :-)
Non, sous Linux, on fait confiance aux développeurs pour fournir les sources
d'un logiciel intéressant, et aux packageurs pour en faire un truc qui
marche, maintenu sur le long terme et mis à jour de manière cohérente. Deux
boulots différents, avec des enjeux bien séparés.
Je prends un exemple simple : une bibliothèque pour un protocole réseau, et
quatre ou cinq applications d'origines diverses qui l'utilisent. Un bug de
sécurité est découvert dans la bibliothèques ; les développeurs de la
bibliothèque publient immédiatement une version corrigée, totalement
compatible avec l'ancienne.
Tu veux compter sur le fait que tous les groupes qui ont publié une
application utilisant cette bibliothèque vont (1) suivre les alertes de
sécurité et (2) avoir une infrastructure de mises à jour impératives ? Même
si c'est le cas, c'est du gaspillage d'efforts considérable de refaire
plusieurs fois la même chose ainsi. Et en pratique, plus de la moitié
n'auront pas fait cet effort, et tu te retrouveras avec des applications
trouées sur ton système.
JEf wrote in message:Cette merde est bien utile je trouve.
À la lumière du reste de tes vues sur l'informatique, ça me confirme dans
mon opinion.Qui parle de dev mac ? Quand je prends libpurple utilisée dans les softs
d'IM, elle n'est pas développée sur mac à la base.
Quoi la libpurple ?
Oui c'est ça avoir le choix. Soit tu prends le binaires et tu fais
confiance au dev de fournir un truc qui fonctionne. Soit tu prends les
sources et tu compiles toi-même. Un peu comme sous linux quoi :-)
Non, sous Linux, on fait confiance aux développeurs pour fournir les sources
d'un logiciel intéressant, et aux packageurs pour en faire un truc qui
marche, maintenu sur le long terme et mis à jour de manière cohérente. Deux
boulots différents, avec des enjeux bien séparés.
Je prends un exemple simple : une bibliothèque pour un protocole réseau, et
quatre ou cinq applications d'origines diverses qui l'utilisent. Un bug de
sécurité est découvert dans la bibliothèques ; les développeurs de la
bibliothèque publient immédiatement une version corrigée, totalement
compatible avec l'ancienne.
Tu veux compter sur le fait que tous les groupes qui ont publié une
application utilisant cette bibliothèque vont (1) suivre les alertes de
sécurité et (2) avoir une infrastructure de mises à jour impératives ? Même
si c'est le cas, c'est du gaspillage d'efforts considérable de refaire
plusieurs fois la même chose ainsi. Et en pratique, plus de la moitié
n'auront pas fait cet effort, et tu te retrouveras avec des applications
trouées sur ton système.
JKB wrote in message :Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
Ah bon ?
Non, bien sûr. C'est le problème de celui qui veut installer / déployer /
packager le logiciel pour Solaris.Non, ça montre juste ta mentalité. Tu ne peux pas reprocher à
quelqu'un d'utiliser Solaris pour de _bonnes_ raisons.
Je ne lui reproche pas, je dis juste que c'est son problème.Et lorsqu'il
utilise Solaris, c'est à toi de t'adapter puisque tu ne peux pas
l'envoyer balader d'un simple revers de main.
Bien sûr que si tu peux l'envoyer balader. Ou alors c'est qu'il te paye pour
administrer ses machines.
Et dans ce cas, excuse-moi de te le dire, mais si ta solution pour
administrer une machine est d'installer des bibliothèques par-ci, par-là au
cas par cas, je n'ai vraiment pas envie d'avoir besoin de tes services.
Là où ça se corse, c'est juste au moment où les
différentes bibliothèques se parchent sur les pieds et que les
versions qui se suivent de la même bibliothèque ont des ABI
subtilement incompatibles.
Si elles ont des ABI différentes, elles ont des SONAME différents, et ça se
voit. Ça se voit moins directement quand c'est une dépendance de second
ordre, mais ça reste visible. Et c'est essentiellement le point délicat du
boulot d'administrateur / packageur de gérer ces cas.
Tu peux utiliser OpenSSL pour cryper un fichier. S'il y a une
faiblesse de OpenSSL, elle est déjà dans le fichier que tu as
chiffré avec une version foireuse de la bibliothèque. Autre argument ?
Et donc puisqu'un vieux fichier a été chiffré avec une faiblesse, continuons
à chiffrer les fichiers suivants avec la même faiblesse ?
JKB wrote in message <slrni629kl.4v8.jkb@rayleigh.systella.fr>:
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
Ah bon ?
Non, bien sûr. C'est le problème de celui qui veut installer / déployer /
packager le logiciel pour Solaris.
Non, ça montre juste ta mentalité. Tu ne peux pas reprocher à
quelqu'un d'utiliser Solaris pour de _bonnes_ raisons.
Je ne lui reproche pas, je dis juste que c'est son problème.
Et lorsqu'il
utilise Solaris, c'est à toi de t'adapter puisque tu ne peux pas
l'envoyer balader d'un simple revers de main.
Bien sûr que si tu peux l'envoyer balader. Ou alors c'est qu'il te paye pour
administrer ses machines.
Et dans ce cas, excuse-moi de te le dire, mais si ta solution pour
administrer une machine est d'installer des bibliothèques par-ci, par-là au
cas par cas, je n'ai vraiment pas envie d'avoir besoin de tes services.
Là où ça se corse, c'est juste au moment où les
différentes bibliothèques se parchent sur les pieds et que les
versions qui se suivent de la même bibliothèque ont des ABI
subtilement incompatibles.
Si elles ont des ABI différentes, elles ont des SONAME différents, et ça se
voit. Ça se voit moins directement quand c'est une dépendance de second
ordre, mais ça reste visible. Et c'est essentiellement le point délicat du
boulot d'administrateur / packageur de gérer ces cas.
Tu peux utiliser OpenSSL pour cryper un fichier. S'il y a une
faiblesse de OpenSSL, elle est déjà dans le fichier que tu as
chiffré avec une version foireuse de la bibliothèque. Autre argument ?
Et donc puisqu'un vieux fichier a été chiffré avec une faiblesse, continuons
à chiffrer les fichiers suivants avec la même faiblesse ?
JKB wrote in message :Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
Ah bon ?
Non, bien sûr. C'est le problème de celui qui veut installer / déployer /
packager le logiciel pour Solaris.Non, ça montre juste ta mentalité. Tu ne peux pas reprocher à
quelqu'un d'utiliser Solaris pour de _bonnes_ raisons.
Je ne lui reproche pas, je dis juste que c'est son problème.Et lorsqu'il
utilise Solaris, c'est à toi de t'adapter puisque tu ne peux pas
l'envoyer balader d'un simple revers de main.
Bien sûr que si tu peux l'envoyer balader. Ou alors c'est qu'il te paye pour
administrer ses machines.
Et dans ce cas, excuse-moi de te le dire, mais si ta solution pour
administrer une machine est d'installer des bibliothèques par-ci, par-là au
cas par cas, je n'ai vraiment pas envie d'avoir besoin de tes services.
Là où ça se corse, c'est juste au moment où les
différentes bibliothèques se parchent sur les pieds et que les
versions qui se suivent de la même bibliothèque ont des ABI
subtilement incompatibles.
Si elles ont des ABI différentes, elles ont des SONAME différents, et ça se
voit. Ça se voit moins directement quand c'est une dépendance de second
ordre, mais ça reste visible. Et c'est essentiellement le point délicat du
boulot d'administrateur / packageur de gérer ces cas.
Tu peux utiliser OpenSSL pour cryper un fichier. S'il y a une
faiblesse de OpenSSL, elle est déjà dans le fichier que tu as
chiffré avec une version foireuse de la bibliothèque. Autre argument ?
Et donc puisqu'un vieux fichier a été chiffré avec une faiblesse, continuons
à chiffrer les fichiers suivants avec la même faiblesse ?
Tu peux très bien packager un logiciel pour un client qui utilise
Solaris alors même que tu n'administres pas ses machines.
Sans commentaires.
Et lorsque tu as un programme qui utilise une fonction d'une
bibliothèque système (au travers d'un autre bibliothèque chargée
dynamiquement) et la même fonction mais d'une bliothèque plus
récente, le truc se casse la gueule malgré les SONAME's différents.
Ça ne t'est jamais venu à l'esprit que tu peux avoir besoin de
relire ces fichiers ?
Ça ne t'est jamais venu à l'esprit que le
chiffrement en question même troué peut être suffisant pour ce que
tu en fais ?
Tu peux très bien packager un logiciel pour un client qui utilise
Solaris alors même que tu n'administres pas ses machines.
Sans commentaires.
Et lorsque tu as un programme qui utilise une fonction d'une
bibliothèque système (au travers d'un autre bibliothèque chargée
dynamiquement) et la même fonction mais d'une bliothèque plus
récente, le truc se casse la gueule malgré les SONAME's différents.
Ça ne t'est jamais venu à l'esprit que tu peux avoir besoin de
relire ces fichiers ?
Ça ne t'est jamais venu à l'esprit que le
chiffrement en question même troué peut être suffisant pour ce que
tu en fais ?
Tu peux très bien packager un logiciel pour un client qui utilise
Solaris alors même que tu n'administres pas ses machines.
Sans commentaires.
Et lorsque tu as un programme qui utilise une fonction d'une
bibliothèque système (au travers d'un autre bibliothèque chargée
dynamiquement) et la même fonction mais d'une bliothèque plus
récente, le truc se casse la gueule malgré les SONAME's différents.
Ça ne t'est jamais venu à l'esprit que tu peux avoir besoin de
relire ces fichiers ?
Ça ne t'est jamais venu à l'esprit que le
chiffrement en question même troué peut être suffisant pour ce que
tu en fais ?
Si je prends la dernière version de libpurple avec les sources stables
de Adium, ça ne fonctionne pas. Soit je prends la version stable d'adium
avec la libpurple de la même époque (avec les backports pour supporter
les changements intervenus sur le réseau MSN) soit je prends la version
beta avec la dernière version de libpurple (et là ça fonctionne).
Exemple liquidsoap, sur debian stable c'est la version 0.9.1 qui est
fournie. La dernière (0.9.2-2) est disponible en .deb sur le site du
dev. Je prends le binaire (.deb) sur le site du dev. Le packageur de
debian n'a rien à voir dans l'histoire. Je fais confiance au dev pour
son .deb.
Passer d'un 2.5.1 à 2.5.2 se fait souvent sans prob. Passer d'un 2.5.X à
2.6 pas toujours. Et tous les dev ne sont pas tous sérieux dans leurs
tests de retro-compatibilité.
Si je prends la dernière version de libpurple avec les sources stables
de Adium, ça ne fonctionne pas. Soit je prends la version stable d'adium
avec la libpurple de la même époque (avec les backports pour supporter
les changements intervenus sur le réseau MSN) soit je prends la version
beta avec la dernière version de libpurple (et là ça fonctionne).
Exemple liquidsoap, sur debian stable c'est la version 0.9.1 qui est
fournie. La dernière (0.9.2-2) est disponible en .deb sur le site du
dev. Je prends le binaire (.deb) sur le site du dev. Le packageur de
debian n'a rien à voir dans l'histoire. Je fais confiance au dev pour
son .deb.
Passer d'un 2.5.1 à 2.5.2 se fait souvent sans prob. Passer d'un 2.5.X à
2.6 pas toujours. Et tous les dev ne sont pas tous sérieux dans leurs
tests de retro-compatibilité.
Si je prends la dernière version de libpurple avec les sources stables
de Adium, ça ne fonctionne pas. Soit je prends la version stable d'adium
avec la libpurple de la même époque (avec les backports pour supporter
les changements intervenus sur le réseau MSN) soit je prends la version
beta avec la dernière version de libpurple (et là ça fonctionne).
Exemple liquidsoap, sur debian stable c'est la version 0.9.1 qui est
fournie. La dernière (0.9.2-2) est disponible en .deb sur le site du
dev. Je prends le binaire (.deb) sur le site du dev. Le packageur de
debian n'a rien à voir dans l'histoire. Je fais confiance au dev pour
son .deb.
Passer d'un 2.5.1 à 2.5.2 se fait souvent sans prob. Passer d'un 2.5.X à
2.6 pas toujours. Et tous les dev ne sont pas tous sérieux dans leurs
tests de retro-compatibilité.
JEf wrote in message:Si je prends la dernière version de libpurple avec les sources stables
de Adium, ça ne fonctionne pas. Soit je prends la version stable d'adium
avec la libpurple de la même époque (avec les backports pour supporter
les changements intervenus sur le réseau MSN) soit je prends la version
beta avec la dernière version de libpurple (et là ça fonctionne).
Et donc ?
Exemple liquidsoap, sur debian stable c'est la version 0.9.1 qui est
fournie. La dernière (0.9.2-2) est disponible en .deb sur le site du
dev. Je prends le binaire (.deb) sur le site du dev. Le packageur de
debian n'a rien à voir dans l'histoire. Je fais confiance au dev pour
son .deb.
Eh bien tu n'as rien compris à l'utilisation d'un système de paquets. Et le
développeurs qui fournit un .deb non plus :
- Un .deb publié seul comme ça (par opposition à un dépôt Apt) est
complètement ignoré lors du processus de mise à jour. Le développeur peut
très bien trouver un bug gravissime, qui risque de faire perdre des
données sans préavis, publier un nouveau .deb sur son site, tu n'en sauras
rien et tu garderas la vieille version buggée jusqu'à ce que le bug te
frappe.
- Les packageurs Debian ont l'infrastructure qui leur permet de tester
globalement la compatibilité des dépendances d'un paquet. Pas le
développeur d'un petit logiciel bien précis. À cause de ça, installer un
paquet d'une origine tierce peut bloquer la mise à jour de certains
composants du système.
Passer d'un 2.5.1 à 2.5.2 se fait souvent sans prob. Passer d'un 2.5.X à
2.6 pas toujours. Et tous les dev ne sont pas tous sérieux dans leurs
tests de retro-compatibilité.
C'est pour ça qu'on compte sur des distributions pour faire le boulot
d'uniformiser le tout.
JEf wrote in message<3L-dnT-RedlGrfzRnZ2dnUVZ7sudnZ2d@giganews.com>:
Si je prends la dernière version de libpurple avec les sources stables
de Adium, ça ne fonctionne pas. Soit je prends la version stable d'adium
avec la libpurple de la même époque (avec les backports pour supporter
les changements intervenus sur le réseau MSN) soit je prends la version
beta avec la dernière version de libpurple (et là ça fonctionne).
Et donc ?
Exemple liquidsoap, sur debian stable c'est la version 0.9.1 qui est
fournie. La dernière (0.9.2-2) est disponible en .deb sur le site du
dev. Je prends le binaire (.deb) sur le site du dev. Le packageur de
debian n'a rien à voir dans l'histoire. Je fais confiance au dev pour
son .deb.
Eh bien tu n'as rien compris à l'utilisation d'un système de paquets. Et le
développeurs qui fournit un .deb non plus :
- Un .deb publié seul comme ça (par opposition à un dépôt Apt) est
complètement ignoré lors du processus de mise à jour. Le développeur peut
très bien trouver un bug gravissime, qui risque de faire perdre des
données sans préavis, publier un nouveau .deb sur son site, tu n'en sauras
rien et tu garderas la vieille version buggée jusqu'à ce que le bug te
frappe.
- Les packageurs Debian ont l'infrastructure qui leur permet de tester
globalement la compatibilité des dépendances d'un paquet. Pas le
développeur d'un petit logiciel bien précis. À cause de ça, installer un
paquet d'une origine tierce peut bloquer la mise à jour de certains
composants du système.
Passer d'un 2.5.1 à 2.5.2 se fait souvent sans prob. Passer d'un 2.5.X à
2.6 pas toujours. Et tous les dev ne sont pas tous sérieux dans leurs
tests de retro-compatibilité.
C'est pour ça qu'on compte sur des distributions pour faire le boulot
d'uniformiser le tout.
JEf wrote in message:Si je prends la dernière version de libpurple avec les sources stables
de Adium, ça ne fonctionne pas. Soit je prends la version stable d'adium
avec la libpurple de la même époque (avec les backports pour supporter
les changements intervenus sur le réseau MSN) soit je prends la version
beta avec la dernière version de libpurple (et là ça fonctionne).
Et donc ?
Exemple liquidsoap, sur debian stable c'est la version 0.9.1 qui est
fournie. La dernière (0.9.2-2) est disponible en .deb sur le site du
dev. Je prends le binaire (.deb) sur le site du dev. Le packageur de
debian n'a rien à voir dans l'histoire. Je fais confiance au dev pour
son .deb.
Eh bien tu n'as rien compris à l'utilisation d'un système de paquets. Et le
développeurs qui fournit un .deb non plus :
- Un .deb publié seul comme ça (par opposition à un dépôt Apt) est
complètement ignoré lors du processus de mise à jour. Le développeur peut
très bien trouver un bug gravissime, qui risque de faire perdre des
données sans préavis, publier un nouveau .deb sur son site, tu n'en sauras
rien et tu garderas la vieille version buggée jusqu'à ce que le bug te
frappe.
- Les packageurs Debian ont l'infrastructure qui leur permet de tester
globalement la compatibilité des dépendances d'un paquet. Pas le
développeur d'un petit logiciel bien précis. À cause de ça, installer un
paquet d'une origine tierce peut bloquer la mise à jour de certains
composants du système.
Passer d'un 2.5.1 à 2.5.2 se fait souvent sans prob. Passer d'un 2.5.X à
2.6 pas toujours. Et tous les dev ne sont pas tous sérieux dans leurs
tests de retro-compatibilité.
C'est pour ça qu'on compte sur des distributions pour faire le boulot
d'uniformiser le tout.
Si je veux utiliser la dernière version stable de libpurple avec la
dernière version stable d'adium ça ne fonctionne pas.
Donc selon toi, un admin doit attendre le bon vouloir d'un packageur
quand son système est instable et un patch disponible.
Haha. Pour les gros trucs et sur archi x86/64 peut-être mais alors en
PPC ou plus exotique je n'y crois pas.
Si je veux utiliser la dernière version stable de libpurple avec la
dernière version stable d'adium ça ne fonctionne pas.
Donc selon toi, un admin doit attendre le bon vouloir d'un packageur
quand son système est instable et un patch disponible.
Haha. Pour les gros trucs et sur archi x86/64 peut-être mais alors en
PPC ou plus exotique je n'y crois pas.
Si je veux utiliser la dernière version stable de libpurple avec la
dernière version stable d'adium ça ne fonctionne pas.
Donc selon toi, un admin doit attendre le bon vouloir d'un packageur
quand son système est instable et un patch disponible.
Haha. Pour les gros trucs et sur archi x86/64 peut-être mais alors en
PPC ou plus exotique je n'y crois pas.
JEf wrote in message:Si je veux utiliser la dernière version stable de libpurple avec la
dernière version stable d'adium ça ne fonctionne pas.
Tant que tu te contenteras de vagues affirmations « ça marche pas », tu ne
pourras rien prouver.
Donc selon toi, un admin doit attendre le bon vouloir d'un packageur
quand son système est instable et un patch disponible.
Tu caricatures au point de n'avoir plus aucune ressemblance avec la réalité.
Haha. Pour les gros trucs et sur archi x86/64 peut-être mais alors en
PPC ou plus exotique je n'y crois pas.
Ta religion ne nous intéresse pas.
JEf wrote in message<Y9idnXk1T_gYp_zRnZ2dnUVZ8iSdnZ2d@giganews.com>:
Si je veux utiliser la dernière version stable de libpurple avec la
dernière version stable d'adium ça ne fonctionne pas.
Tant que tu te contenteras de vagues affirmations « ça marche pas », tu ne
pourras rien prouver.
Donc selon toi, un admin doit attendre le bon vouloir d'un packageur
quand son système est instable et un patch disponible.
Tu caricatures au point de n'avoir plus aucune ressemblance avec la réalité.
Haha. Pour les gros trucs et sur archi x86/64 peut-être mais alors en
PPC ou plus exotique je n'y crois pas.
Ta religion ne nous intéresse pas.
JEf wrote in message:Si je veux utiliser la dernière version stable de libpurple avec la
dernière version stable d'adium ça ne fonctionne pas.
Tant que tu te contenteras de vagues affirmations « ça marche pas », tu ne
pourras rien prouver.
Donc selon toi, un admin doit attendre le bon vouloir d'un packageur
quand son système est instable et un patch disponible.
Tu caricatures au point de n'avoir plus aucune ressemblance avec la réalité.
Haha. Pour les gros trucs et sur archi x86/64 peut-être mais alors en
PPC ou plus exotique je n'y crois pas.
Ta religion ne nous intéresse pas.
Il n'y a rien à prouver
Il n'y a rien à prouver
Il n'y a rien à prouver
Pas dans le cas d'espèce mais quand bien même je ne vais pas laisser mon
serveur crasher parce que ce soft n'est pas une priorité chez debian.
Pas dans le cas d'espèce mais quand bien même je ne vais pas laisser mon
serveur crasher parce que ce soft n'est pas une priorité chez debian.
Pas dans le cas d'espèce mais quand bien même je ne vais pas laisser mon
serveur crasher parce que ce soft n'est pas une priorité chez debian.