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.
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 ?
Qui fait appel à spamassassin? - PostFix? - Procmail? - ...
Un des problèmes de la compilation (j'entend par là ne pas utiliser les packages) c'est justement que les autres éléments du système cherchent spamassassin (par exemple) à un endroit bien précis, et que toi quand tu l'a compilé, tu l'as foutu là ou tu veux. Il y a une certaine cohésion qui est apportée par le fait qu'on reste sous le gestionnaire de package. Quand le gesiotnnaire de package est bon... Le système pourrait aussi scanner les répertoires probables ou peut se trouver SA, mais dans ton cas, il ne l'a pas fait.
Jazzoroastre wrote:
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 ?
Qui fait appel à spamassassin?
- PostFix?
- Procmail?
- ...
Un des problèmes de la compilation (j'entend par là ne pas utiliser les
packages) c'est justement que les autres éléments du système cherchent
spamassassin (par exemple) à un endroit bien précis, et que toi quand tu
l'a compilé, tu l'as foutu là ou tu veux.
Il y a une certaine cohésion qui est apportée par le fait qu'on reste sous
le gestionnaire de package. Quand le gesiotnnaire de package est bon...
Le système pourrait aussi scanner les répertoires probables ou peut se
trouver SA, mais dans ton cas, il ne l'a pas fait.
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 ?
Qui fait appel à spamassassin? - PostFix? - Procmail? - ...
Un des problèmes de la compilation (j'entend par là ne pas utiliser les packages) c'est justement que les autres éléments du système cherchent spamassassin (par exemple) à un endroit bien précis, et que toi quand tu l'a compilé, tu l'as foutu là ou tu veux. Il y a une certaine cohésion qui est apportée par le fait qu'on reste sous le gestionnaire de package. Quand le gesiotnnaire de package est bon... Le système pourrait aussi scanner les répertoires probables ou peut se trouver SA, mais dans ton cas, il ne l'a pas fait.
patpro ~ Patrick Proniewski
In article <es9egi$2bgv$, "Mihamina Rakotomandimby (R12y)" wrote:
Jazzoroastre wrote:
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 ?
Qui fait appel à spamassassin? - PostFix? - Procmail? - ...
dans un montage classic amavisd-new/SA/clamav, c'est amavisd-new qui utilise la librairie PERL SpamAssassin.
Je soupçonne que la lib utilisée par amavis n'est pas installée au même endroit que le produit de l'installation de la nouvelle version.
patpro
-- http://www.patpro.net/
In article <es9egi$2bgv$1@cabale.usenet-fr.net>,
"Mihamina Rakotomandimby (R12y)" <mihamina@rktmb.org> wrote:
Jazzoroastre wrote:
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 ?
Qui fait appel à spamassassin?
- PostFix?
- Procmail?
- ...
dans un montage classic amavisd-new/SA/clamav, c'est amavisd-new qui
utilise la librairie PERL SpamAssassin.
Je soupçonne que la lib utilisée par amavis n'est pas installée au même
endroit que le produit de l'installation de la nouvelle version.
Je soupçonne que la lib utilisée par amavis n'est pas installée au même endroit que le produit de l'installation de la nouvelle version.
patpro
Ok resolu en desinstallant l'ancien paquet avec apt-get remove puis resintallant le nouveau spamassassin par make install. Merci à tous.
Sébastien Kirche
Le 2 mars 2007 à 18:31, Jazzoroastre a formulé :
Ok resolu en desinstallant l'ancien paquet avec apt-get remove puis resintallant le nouveau spamassassin par make install.
Sauf que maintenant apt n'est pas au courant que tu as spamassassin et ça peut être source d'emmerdes.
Tu n'as plus les dépendances nécessaires à certaines applis que tu pourrais vouloir installer (apt-cache rdepends spamassassin pour savoir lesquelles et il y en a) et si tu les installes, apt te remettra le paquet que tu as supprimé et tu te retrouveras avec une régression. -- Sébastien Kirche
Le 2 mars 2007 à 18:31, Jazzoroastre a formulé :
Ok resolu en desinstallant l'ancien paquet avec apt-get remove puis
resintallant le nouveau spamassassin par make install.
Sauf que maintenant apt n'est pas au courant que tu as spamassassin et
ça peut être source d'emmerdes.
Tu n'as plus les dépendances nécessaires à certaines applis que tu
pourrais vouloir installer (apt-cache rdepends spamassassin pour savoir
lesquelles et il y en a) et si tu les installes, apt te remettra le
paquet que tu as supprimé et tu te retrouveras avec une régression.
--
Sébastien Kirche
Ok resolu en desinstallant l'ancien paquet avec apt-get remove puis resintallant le nouveau spamassassin par make install.
Sauf que maintenant apt n'est pas au courant que tu as spamassassin et ça peut être source d'emmerdes.
Tu n'as plus les dépendances nécessaires à certaines applis que tu pourrais vouloir installer (apt-cache rdepends spamassassin pour savoir lesquelles et il y en a) et si tu les installes, apt te remettra le paquet que tu as supprimé et tu te retrouveras avec une régression. -- Sébastien Kirche
Mihamina (R12y) Rakotomandimby
Sébastien Kirche wrote:
Sauf que maintenant apt n'est pas au courant
Tu sais, de nos jours, on a meme besoin de mettre sur les boites de cigarette un avertissement qui dit que le tabac tue. On a beau prévenir de la sorte, y en a qui achètent... Alors... (Si si , Linux est une drogue!)
Sébastien Kirche wrote:
Sauf que maintenant apt n'est pas au courant
Tu sais, de nos jours, on a meme besoin de mettre sur les boites de
cigarette un avertissement qui dit que le tabac tue. On a beau prévenir de
la sorte, y en a qui achètent... Alors... (Si si , Linux est une drogue!)
Tu sais, de nos jours, on a meme besoin de mettre sur les boites de cigarette un avertissement qui dit que le tabac tue. On a beau prévenir de la sorte, y en a qui achètent... Alors... (Si si , Linux est une drogue!)
miterrandir
Mihamina Rakotomandimby (R12y) sur fr.comp.os.linux.configuration le vendredi 02 mars 2007 16:09
Un des problèmes de la compilation (j'entend par là ne pas utiliser les packages) c'est justement que les autres éléments du système cherchent spamassassin (par exemple) à un endroit bien précis, et que toi quand tu l'a compilé, tu l'as foutu là ou tu veux.
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le choix du chemin d'install lors d'une installation à partir des sources de spamassassin. Si "l'endroit bien précis" n'est pas respecté, c'est pas du coté de l'installation par les sources qu'il faut chercher.
Mihamina Rakotomandimby (R12y) sur fr.comp.os.linux.configuration le
vendredi 02 mars 2007 16:09
Un des problèmes de la compilation (j'entend par là ne pas utiliser les
packages) c'est justement que les autres éléments du système cherchent
spamassassin (par exemple) à un endroit bien précis, et que toi quand tu
l'a compilé, tu l'as foutu là ou tu veux.
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le
choix du chemin d'install lors d'une installation à partir des sources de
spamassassin. Si "l'endroit bien précis" n'est pas respecté, c'est pas du
coté de l'installation par les sources qu'il faut chercher.
Mihamina Rakotomandimby (R12y) sur fr.comp.os.linux.configuration le vendredi 02 mars 2007 16:09
Un des problèmes de la compilation (j'entend par là ne pas utiliser les packages) c'est justement que les autres éléments du système cherchent spamassassin (par exemple) à un endroit bien précis, et que toi quand tu l'a compilé, tu l'as foutu là ou tu veux.
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le choix du chemin d'install lors d'une installation à partir des sources de spamassassin. Si "l'endroit bien précis" n'est pas respecté, c'est pas du coté de l'installation par les sources qu'il faut chercher.
Sébastien Kirche
Le 3 mars 2007 à 12:27, miterrandir a formulé :
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le choix du chemin d'install lors d'une installation à partir des sources de spamassassin.
Le script configure ne connaît pas PREFIX & compagnie ? -- Sébastien Kirche
Le 3 mars 2007 à 12:27, miterrandir a formulé :
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a
pas le choix du chemin d'install lors d'une installation à partir des
sources de spamassassin.
Le script configure ne connaît pas PREFIX & compagnie ?
--
Sébastien Kirche
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le choix du chemin d'install lors d'une installation à partir des sources de spamassassin.
Le script configure ne connaît pas PREFIX & compagnie ? -- Sébastien Kirche
miterrandir
Sébastien Kirche sur fr.comp.os.linux.configuration le samedi 03 mars 2007 15:45
Le 3 mars 2007 à 12:27, miterrandir a formulé :
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le choix du chemin d'install lors d'une installation à partir des sources de spamassassin.
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 ? 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é ?).
Sébastien Kirche sur fr.comp.os.linux.configuration le samedi 03 mars 2007
15:45
Le 3 mars 2007 à 12:27, miterrandir a formulé :
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a
pas le choix du chemin d'install lors d'une installation à partir des
sources de spamassassin.
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 ? 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é ?).
Sébastien Kirche sur fr.comp.os.linux.configuration le samedi 03 mars 2007 15:45
Le 3 mars 2007 à 12:27, miterrandir a formulé :
Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le choix du chemin d'install lors d'une installation à partir des sources de spamassassin.
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 ? 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é ?).
Mihamina (R12y) Rakotomandimby
miterrandir wrote:
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é ?).
La modularité/flexibilité a _toujours_ une utilité.
miterrandir wrote:
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é ?).
La modularité/flexibilité a _toujours_ une utilité.
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é ?).
La modularité/flexibilité a _toujours_ une utilité.
Sébastien Kirche
Le 3 mars 2007 à 19:36, miterrandir a formulé :
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.
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.
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. -- Sébastien Kirche
Le 3 mars 2007 à 19:36, miterrandir a formulé :
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.
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.
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.
--
Sébastien Kirche
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.
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.
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. -- Sébastien Kirche
