Je ne comprends pas bien qqchose :
J'ai fait une recompilation puis installation de la dernière version de
spamassasssin (3.1.8) avec un make install qui s'est bien fini, puis n
reboot : nickel.
Or quand je regarde les traces dans les sources de mes mails, je vois
toujours :
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on ....
Comment être sûr que c'est la version 3.1.8 qui tourne ?
Ou bien, si ce que je présume est que ce n'est pas elle qui tourne, comment
faire pour la faire remplacer l'ancienne.
Sébastien Kirche sur fr.comp.os.linux.configuration le dimanche 04 mars 2007 14:20
Bonjour
Le script configure ne connaît pas PREFIX & compagnie ?
Si, passer des arguments de configuration consiste à modifier (le mot est sans doute mal choisi, d'où le 'bidouiller') le Makefile il me semble ?
Oui et non. Oui car le passage de paramètre PREFIX à configure se traduit par une modification du Makefile standard. Non car c'est prévu pour justement dans les cas où on ne souhaite pas (ou ne peut pas) installer le résultat dans les répertoires par défaut. Soit parce qu'on n'a pas le droit (utilisateur qui compile une appli dans son $HOME) ou parce qu'on souhaite tester une version en parallèle de la version en place par exemple.
Oui, merci mais je connais parfaitement la fonction d'un prefix. Vous jouez un peu sur les mots en généralisant mon commentaire. Je parle de spamassassin pour une installation/upgrade normale, où une copie du contenu des répertoires concernés avant le make install suffit pour se rassurer.
En tout cas c'est infiniment plus pratique et plus sûr de passer des arguments à configure que d'aller modifier le Makefile résultant. Et c'est fait pour.
Désolé si j'ai laissé sous entendre le contraire. En disant bidouiller (je répète) je pensais à changer les paramètres, y compris lors de la commande. C'était une façon de parler...
Ce que je veux dire c'est que si on fait (comme indiqué dans la doc ?) perl Makefile.PL, on ne pose pas de question sur les chemins d'accès, comme c'est parfois le cas (lorsque ça a une utilité ?).
Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui marche de façon universelle est illusoire.
SA est un programme qui s'installe, s'upgrade et se configure très bien. Il est je crois fonctionnel avec la configuration par défaut. On est pas en présence d'une application lourde style apache, sendmail ou open-xchange.
Je suis d'accord sur le fond de "prendre son temps pour bien faire les choses", mais si on peut aussi éviter d'en perdre c'est bien. cdlt
Sébastien Kirche sur fr.comp.os.linux.configuration le dimanche 04 mars 2007
14:20
Bonjour
Le script configure ne connaît pas PREFIX & compagnie ?
Si, passer des arguments de configuration consiste à modifier (le mot
est sans doute mal choisi, d'où le 'bidouiller') le Makefile il me
semble ?
Oui et non.
Oui car le passage de paramètre PREFIX à configure se traduit par une
modification du Makefile standard.
Non car c'est prévu pour justement dans les cas où on ne souhaite pas
(ou ne peut pas) installer le résultat dans les répertoires par défaut.
Soit parce qu'on n'a pas le droit (utilisateur qui compile une appli
dans son $HOME) ou parce qu'on souhaite tester une version en parallèle
de la version en place par exemple.
Oui, merci mais je connais parfaitement la fonction d'un prefix.
Vous jouez un peu sur les mots en généralisant mon commentaire. Je parle de
spamassassin pour une installation/upgrade normale, où une copie du contenu
des répertoires concernés avant le make install suffit pour se rassurer.
En tout cas c'est infiniment plus pratique et plus sûr de passer des
arguments à configure que d'aller modifier le Makefile résultant. Et
c'est fait pour.
Désolé si j'ai laissé sous entendre le contraire. En disant bidouiller (je
répète) je pensais à changer les paramètres, y compris lors de la commande.
C'était une façon de parler...
Ce que je veux dire c'est que si on fait (comme indiqué dans
la doc ?) perl Makefile.PL, on ne pose pas de question sur les chemins
d'accès, comme c'est parfois le cas (lorsque ça a une utilité ?).
Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui
marche de façon universelle est illusoire.
SA est un programme qui s'installe, s'upgrade et se configure très bien. Il
est je crois fonctionnel avec la configuration par défaut. On est pas en
présence d'une application lourde style apache, sendmail ou open-xchange.
Je suis d'accord sur le fond de "prendre son temps pour bien faire les
choses", mais si on peut aussi éviter d'en perdre c'est bien.
cdlt
Sébastien Kirche sur fr.comp.os.linux.configuration le dimanche 04 mars 2007 14:20
Bonjour
Le script configure ne connaît pas PREFIX & compagnie ?
Si, passer des arguments de configuration consiste à modifier (le mot est sans doute mal choisi, d'où le 'bidouiller') le Makefile il me semble ?
Oui et non. Oui car le passage de paramètre PREFIX à configure se traduit par une modification du Makefile standard. Non car c'est prévu pour justement dans les cas où on ne souhaite pas (ou ne peut pas) installer le résultat dans les répertoires par défaut. Soit parce qu'on n'a pas le droit (utilisateur qui compile une appli dans son $HOME) ou parce qu'on souhaite tester une version en parallèle de la version en place par exemple.
Oui, merci mais je connais parfaitement la fonction d'un prefix. Vous jouez un peu sur les mots en généralisant mon commentaire. Je parle de spamassassin pour une installation/upgrade normale, où une copie du contenu des répertoires concernés avant le make install suffit pour se rassurer.
En tout cas c'est infiniment plus pratique et plus sûr de passer des arguments à configure que d'aller modifier le Makefile résultant. Et c'est fait pour.
Désolé si j'ai laissé sous entendre le contraire. En disant bidouiller (je répète) je pensais à changer les paramètres, y compris lors de la commande. C'était une façon de parler...
Ce que je veux dire c'est que si on fait (comme indiqué dans la doc ?) perl Makefile.PL, on ne pose pas de question sur les chemins d'accès, comme c'est parfois le cas (lorsque ça a une utilité ?).
Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui marche de façon universelle est illusoire.
SA est un programme qui s'installe, s'upgrade et se configure très bien. Il est je crois fonctionnel avec la configuration par défaut. On est pas en présence d'une application lourde style apache, sendmail ou open-xchange.
Je suis d'accord sur le fond de "prendre son temps pour bien faire les choses", mais si on peut aussi éviter d'en perdre c'est bien. cdlt
Sébastien Kirche
Le 4 mars 2007 à 19:16, miterrandir vraute :
Oui, merci mais je connais parfaitement la fonction d'un prefix. Vous jouez un peu sur les mots en généralisant mon commentaire. Je parle de spamassassin pour une installation/upgrade normale, où une copie du contenu des répertoires concernés avant le make install suffit pour se rassurer.
En tout cas c'est infiniment plus pratique et plus sûr de passer des arguments à configure que d'aller modifier le Makefile résultant. Et c'est fait pour.
Désolé si j'ai laissé sous entendre le contraire. En disant bidouiller (je répète) je pensais à changer les paramètres, y compris lors de la commande. C'était une façon de parler...
OK, j'avais compris la remarque dans le sens ou le changement des paramètres par défaut n'était pas possible. Et ensuite que l'utilisation de préfixe était inutile. Donc nous sommes d'accord.
Ce que je veux dire c'est que si on fait (comme indiqué dans la doc ?) perl Makefile.PL, on ne pose pas de question sur les chemins d'accès, comme c'est parfois le cas (lorsque ça a une utilité ?).
Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui marche de façon universelle est illusoire.
SA est un programme qui s'installe, s'upgrade et se configure très bien. Il est je crois fonctionnel avec la configuration par défaut. On est pas en présence d'une application lourde style apache, sendmail ou open-xchange.
Je n'ai également jamais eu de problème pour l'installer et l'upgrader (mais via mon gestionnaire de packages).
Je suis d'accord sur le fond de "prendre son temps pour bien faire les choses", mais si on peut aussi éviter d'en perdre c'est bien.
Oui. C'est bien pourquoi la démarche décrite par l'OP (court-circuiter le gestionnaire de packages et installer par les sources) est inutile et source de perte de temps et d'ennuis.
-- Sébastien Kirche
Le 4 mars 2007 à 19:16, miterrandir vraute :
Oui, merci mais je connais parfaitement la fonction d'un prefix. Vous
jouez un peu sur les mots en généralisant mon commentaire. Je parle de
spamassassin pour une installation/upgrade normale, où une copie du
contenu des répertoires concernés avant le make install suffit pour se
rassurer.
En tout cas c'est infiniment plus pratique et plus sûr de passer des
arguments à configure que d'aller modifier le Makefile résultant. Et
c'est fait pour.
Désolé si j'ai laissé sous entendre le contraire. En disant bidouiller
(je répète) je pensais à changer les paramètres, y compris lors de la
commande. C'était une façon de parler...
OK, j'avais compris la remarque dans le sens ou le changement des
paramètres par défaut n'était pas possible. Et ensuite que l'utilisation
de préfixe était inutile.
Donc nous sommes d'accord.
Ce que je veux dire c'est que si on fait (comme indiqué dans la
doc ?) perl Makefile.PL, on ne pose pas de question sur les
chemins d'accès, comme c'est parfois le cas (lorsque ça a une
utilité ?).
Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui
marche de façon universelle est illusoire.
SA est un programme qui s'installe, s'upgrade et se configure très
bien. Il est je crois fonctionnel avec la configuration par défaut. On
est pas en présence d'une application lourde style apache, sendmail ou
open-xchange.
Je n'ai également jamais eu de problème pour l'installer et l'upgrader
(mais via mon gestionnaire de packages).
Je suis d'accord sur le fond de "prendre son temps pour bien faire les
choses", mais si on peut aussi éviter d'en perdre c'est bien.
Oui. C'est bien pourquoi la démarche décrite par l'OP (court-circuiter
le gestionnaire de packages et installer par les sources) est inutile et
source de perte de temps et d'ennuis.
Oui, merci mais je connais parfaitement la fonction d'un prefix. Vous jouez un peu sur les mots en généralisant mon commentaire. Je parle de spamassassin pour une installation/upgrade normale, où une copie du contenu des répertoires concernés avant le make install suffit pour se rassurer.
En tout cas c'est infiniment plus pratique et plus sûr de passer des arguments à configure que d'aller modifier le Makefile résultant. Et c'est fait pour.
Désolé si j'ai laissé sous entendre le contraire. En disant bidouiller (je répète) je pensais à changer les paramètres, y compris lors de la commande. C'était une façon de parler...
OK, j'avais compris la remarque dans le sens ou le changement des paramètres par défaut n'était pas possible. Et ensuite que l'utilisation de préfixe était inutile. Donc nous sommes d'accord.
Ce que je veux dire c'est que si on fait (comme indiqué dans la doc ?) perl Makefile.PL, on ne pose pas de question sur les chemins d'accès, comme c'est parfois le cas (lorsque ça a une utilité ?).
Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui marche de façon universelle est illusoire.
SA est un programme qui s'installe, s'upgrade et se configure très bien. Il est je crois fonctionnel avec la configuration par défaut. On est pas en présence d'une application lourde style apache, sendmail ou open-xchange.
Je n'ai également jamais eu de problème pour l'installer et l'upgrader (mais via mon gestionnaire de packages).
Je suis d'accord sur le fond de "prendre son temps pour bien faire les choses", mais si on peut aussi éviter d'en perdre c'est bien.
Oui. C'est bien pourquoi la démarche décrite par l'OP (court-circuiter le gestionnaire de packages et installer par les sources) est inutile et source de perte de temps et d'ennuis.
-- Sébastien Kirche
Sébastien Kirche
Le 5 mars 2007 à 10:10, Jazzoroastre vraute :
Ok mais quelle serait alors la bonne solution ?
Quel est l'usage de ton poste, et quelle version utilises-tu ? D'après les versions évoquées je dirais que tu es en stable (sarge) ou testing (etch).
Vu que l'installe par un apt-get instal SA ne m'instal pas une version récente (on est parti de là). Je crois qu'on peut-on recréer un paquet installable à partir des sources, c'est ça la bonne démarche ?
Les paquets sources contiennent les sources correspondantes aux mêmes paquets en versions binaires, donc tu n'auras pas les dernières sources.
Si tu n'es pas sur un serveur en production (qui nécessite plus de stabilité que de version fraîche du jour) une solution peut être d'ajouter les sources testing et sid (unstable), de préférer la version stable mais de demander explicitement l'installation d'une version récente de spamassassin qui ira aussi chercher les version nécessaires des dépendances. Attention cette solution n'est pas forcément anodine en rajoutant du sid on peut aussi ajouter des désagréments. Perso je suis en unstable sans souci particulier (mais il vaut mieux utiliser apt-listbugs).
Tu aurais la version 3.1.7 en allant chercher dans sid.
Si tu utilises 2 sources (stable et testing) tu peux utiliser la directive APT::Default-Release "stable"; dans ton /etc/apt/apt.conf pour préférer stable et tu peux demander l'installation d'une version testing avec apt-get install lepaquetvoulu/testing
Si tu utilises plus de 2 sources (stable, testing et unstable) pour préférer une source sur les autres default-release ne fonctionne plus et il faut passer par la directive Pin-Priority dans /etc/apt/preferences pour affecter une priorité plus élevée à stable.
-- Sébastien Kirche
Le 5 mars 2007 à 10:10, Jazzoroastre vraute :
Ok mais quelle serait alors la bonne solution ?
Quel est l'usage de ton poste, et quelle version utilises-tu ? D'après
les versions évoquées je dirais que tu es en stable (sarge) ou testing
(etch).
Vu que l'installe par un apt-get instal SA ne m'instal pas une version
récente (on est parti de là). Je crois qu'on peut-on recréer un paquet
installable à partir des sources, c'est ça la bonne démarche ?
Les paquets sources contiennent les sources correspondantes aux mêmes
paquets en versions binaires, donc tu n'auras pas les dernières sources.
Si tu n'es pas sur un serveur en production (qui nécessite plus de
stabilité que de version fraîche du jour) une solution peut être
d'ajouter les sources testing et sid (unstable), de préférer la version
stable mais de demander explicitement l'installation d'une version
récente de spamassassin qui ira aussi chercher les version nécessaires
des dépendances. Attention cette solution n'est pas forcément anodine en
rajoutant du sid on peut aussi ajouter des désagréments. Perso je suis
en unstable sans souci particulier (mais il vaut mieux utiliser
apt-listbugs).
Tu aurais la version 3.1.7 en allant chercher dans sid.
Si tu utilises 2 sources (stable et testing) tu peux utiliser la
directive APT::Default-Release "stable"; dans ton /etc/apt/apt.conf pour
préférer stable et tu peux demander l'installation d'une version testing
avec apt-get install lepaquetvoulu/testing
Si tu utilises plus de 2 sources (stable, testing et unstable) pour
préférer une source sur les autres default-release ne fonctionne plus et
il faut passer par la directive Pin-Priority dans /etc/apt/preferences
pour affecter une priorité plus élevée à stable.
Quel est l'usage de ton poste, et quelle version utilises-tu ? D'après les versions évoquées je dirais que tu es en stable (sarge) ou testing (etch).
Vu que l'installe par un apt-get instal SA ne m'instal pas une version récente (on est parti de là). Je crois qu'on peut-on recréer un paquet installable à partir des sources, c'est ça la bonne démarche ?
Les paquets sources contiennent les sources correspondantes aux mêmes paquets en versions binaires, donc tu n'auras pas les dernières sources.
Si tu n'es pas sur un serveur en production (qui nécessite plus de stabilité que de version fraîche du jour) une solution peut être d'ajouter les sources testing et sid (unstable), de préférer la version stable mais de demander explicitement l'installation d'une version récente de spamassassin qui ira aussi chercher les version nécessaires des dépendances. Attention cette solution n'est pas forcément anodine en rajoutant du sid on peut aussi ajouter des désagréments. Perso je suis en unstable sans souci particulier (mais il vaut mieux utiliser apt-listbugs).
Tu aurais la version 3.1.7 en allant chercher dans sid.
Si tu utilises 2 sources (stable et testing) tu peux utiliser la directive APT::Default-Release "stable"; dans ton /etc/apt/apt.conf pour préférer stable et tu peux demander l'installation d'une version testing avec apt-get install lepaquetvoulu/testing
Si tu utilises plus de 2 sources (stable, testing et unstable) pour préférer une source sur les autres default-release ne fonctionne plus et il faut passer par la directive Pin-Priority dans /etc/apt/preferences pour affecter une priorité plus élevée à stable.
-- Sébastien Kirche
Sébastien Kirche
Le 5 mars 2007 à 14:16, Sébastien Monbrun aka TiChou a dit :
C'est compliqué Debian. :-)
Pas plus que d'utiliser un ordinateur :) Remarque que mes explications sont peut-être confuses vu que je ne suis qu'un utilisateur (ce qui se conçoit bien s'énonce clairement, toussa) :)
Gentoo a la notion de paquets stabilisés & en cours de dévérolage où on est toujours sur le bleeding edge des dernières sources ?
<troll mode=désinformation> C'est quand même compliqué Gentoo, en tout cas plus que Debian puisque j'utilise le second depuis longtemps et que je n'ai jamais réussi à installer le premier... :P </troll>
-- Sébastien Kirche
Le 5 mars 2007 à 14:16, Sébastien Monbrun aka TiChou a dit :
C'est compliqué Debian. :-)
Pas plus que d'utiliser un ordinateur :)
Remarque que mes explications sont peut-être confuses vu que je ne suis
qu'un utilisateur (ce qui se conçoit bien s'énonce clairement, toussa) :)
Gentoo a la notion de paquets stabilisés & en cours de dévérolage où on
est toujours sur le bleeding edge des dernières sources ?
<troll mode=désinformation>
C'est quand même compliqué Gentoo, en tout cas plus que Debian puisque
j'utilise le second depuis longtemps et que je n'ai jamais réussi à
installer le premier... :P
</troll>
Le 5 mars 2007 à 14:16, Sébastien Monbrun aka TiChou a dit :
C'est compliqué Debian. :-)
Pas plus que d'utiliser un ordinateur :) Remarque que mes explications sont peut-être confuses vu que je ne suis qu'un utilisateur (ce qui se conçoit bien s'énonce clairement, toussa) :)
Gentoo a la notion de paquets stabilisés & en cours de dévérolage où on est toujours sur le bleeding edge des dernières sources ?
<troll mode=désinformation> C'est quand même compliqué Gentoo, en tout cas plus que Debian puisque j'utilise le second depuis longtemps et que je n'ai jamais réussi à installer le premier... :P </troll>
-- Sébastien Kirche
Sébastien Kirche
Le 5 mars 2007 à 15:46, Sébastien Monbrun aka TiChou vraute :
Gentoo a la notion de paquets stabilisés & en cours de dévérolage où on est toujours sur le bleeding edge des dernières sources ?
Ça va plus loin que ça. Il y a plusieurs niveaux de « stabilité ». [...]
Hop, encore un post de référence de ta part sur Gentoo. Je finirai bien par y arriver...
-- Sébastien Kirche
Le 5 mars 2007 à 15:46, Sébastien Monbrun aka TiChou vraute :
Gentoo a la notion de paquets stabilisés & en cours de dévérolage où
on est toujours sur le bleeding edge des dernières sources ?
Ça va plus loin que ça. Il y a plusieurs niveaux de « stabilité ».
[...]
Hop, encore un post de référence de ta part sur Gentoo. Je finirai bien
par y arriver...
Le 5 mars 2007 à 15:46, Sébastien Monbrun aka TiChou vraute :
Gentoo a la notion de paquets stabilisés & en cours de dévérolage où on est toujours sur le bleeding edge des dernières sources ?
Ça va plus loin que ça. Il y a plusieurs niveaux de « stabilité ». [...]
Hop, encore un post de référence de ta part sur Gentoo. Je finirai bien par y arriver...
-- Sébastien Kirche
Sébastien Kirche
Le 7 mars 2007 à 07:49, Cumbalero vraute :
Et précisément sur le troll en cours, je ne vois pas en quoi modifier un fichier /etc/portage/package.keywords rend Gentoo moins compliqué que modifier le fichier /etc/apt/apt.conf. Depuis que j'utilise apt-build, je ne vois plus un seul avantage à Gentoo.
Meuhnon, c'est pas un troll :)
Depuis maintenant quelque temps que je connais Tichou, je sais que c'est un aficionado de Gentoo qu'il maîtrise parfaitement (il n'y a qu'à voir le contenu de ses explications), alors que de mon côté j'en suis à 4 ans parfaitement satisfait de Debian. Et de temps en il fait un peu de pub ;)
-- Sébastien Kirche
Le 7 mars 2007 à 07:49, Cumbalero vraute :
Et précisément sur le troll en cours, je ne vois pas en quoi modifier
un fichier /etc/portage/package.keywords rend Gentoo moins compliqué
que modifier le fichier /etc/apt/apt.conf. Depuis que j'utilise
apt-build, je ne vois plus un seul avantage à Gentoo.
Meuhnon, c'est pas un troll :)
Depuis maintenant quelque temps que je connais Tichou, je sais que c'est
un aficionado de Gentoo qu'il maîtrise parfaitement (il n'y a qu'à voir
le contenu de ses explications), alors que de mon côté j'en suis à 4 ans
parfaitement satisfait de Debian. Et de temps en il fait un peu de pub ;)
Et précisément sur le troll en cours, je ne vois pas en quoi modifier un fichier /etc/portage/package.keywords rend Gentoo moins compliqué que modifier le fichier /etc/apt/apt.conf. Depuis que j'utilise apt-build, je ne vois plus un seul avantage à Gentoo.
Meuhnon, c'est pas un troll :)
Depuis maintenant quelque temps que je connais Tichou, je sais que c'est un aficionado de Gentoo qu'il maîtrise parfaitement (il n'y a qu'à voir le contenu de ses explications), alors que de mon côté j'en suis à 4 ans parfaitement satisfait de Debian. Et de temps en il fait un peu de pub ;)
-- Sébastien Kirche
Mihamina (R12y) Rakotomandimby
miterrandir wrote:
mais si on peut aussi éviter d'en perdre c'est bien
Il en perdra à coup sur à un moment ou un autre si il sort n'improte comment du gestionnaire de package. Il fut un temps ou il était fastidieux et emmerdant de rester sous le gestionnaire de package. Ce temps est révolu.
miterrandir wrote:
mais si on peut aussi éviter d'en perdre c'est bien
Il en perdra à coup sur à un moment ou un autre si il sort n'improte comment
du gestionnaire de package.
Il fut un temps ou il était fastidieux et emmerdant de rester sous le
gestionnaire de package. Ce temps est révolu.
mais si on peut aussi éviter d'en perdre c'est bien
Il en perdra à coup sur à un moment ou un autre si il sort n'improte comment du gestionnaire de package. Il fut un temps ou il était fastidieux et emmerdant de rester sous le gestionnaire de package. Ce temps est révolu.
