2011-09-14 2 views
16

Parce que je dois installer plusieurs versions de Python sur plusieurs serveurs Oracle Linux qui sont construits via un processus kickstart, je voulais construire un rpm python pour notre dépôt yum. J'ai été capable de construire Python manuellement en utilisant 'make altinstall' qui ne s'installe pas sur votre installation Python système par défaut, donc je pensais que ce serait le chemin à parcourir.RPM Python que j'ai construit ne va pas installer

Après beaucoup d'essais et d'erreurs, j'ai réussi à construire un régime commençant par un paquet python .bz2 2.7 - mais maintenant, quand j'essaie de l'installer, je reçois une erreur:

error: Failed dependencies: 
    /usr/local/bin/python is needed by Python-2.7.2-1.i386 

Que .. ???? Python est ce que j'essaye d'installer !!! Et le système Python par défaut (2.4) est dans/usr/bin/python !!! Et mon emplacement de prototypage pour le répertoire python est /tmp/python2.7 (et l'exécutable était /tmp/python2.7/bin/python2.7). Alors pourquoi regarde-t-il/usr/local/bin?

Voici le coeur de mon SPEC RPM:

%prep 
%setup -q 

%build 
./configure --prefix=/tmp/python2.7 
make 

%install 

make altinstall 

je regarde de plus près le journal de construction rpm et je vois:

Requires: /bin/sh /tmp/python2.7/bin/python2.7 /usr/bin/env /usr/local/bin/python libc.so.6 libc.so.6(GLIBC_2.0)...[a lot more...] 

Ok, donc il est là/usr/local/bin entre ... Maintenant, la question est, comment détermine-t-il ces exigences? Ai-je spécifié quelque chose de mal? Dois-je remplacer quelque chose? Comme beaucoup de débutants rpm, je reçois la partie build, mais je ne "grok" pas vraiment ce qui se passe à la fin de rpmbuild et ce qui est réellement mis dans le fichier rpm (autre que les fichiers que vous spécifiez dans% files) et ensuite ce qui se passe réellement lorsque vous faites l'installation de RPM. Est-ce que quelqu'un peut suggérer pourquoi mon installation échoue ou ce que je pourrais lire pour comprendre pourquoi ma construction de rpm exige ce que j'essaye de construire?

Répondre

18

Vous devriez être en mesure de résoudre ce problème en ajoutant la ligne suivante à votre fichier de spécification:

AutoReq: no 

Voici ma compréhension des raisons pour lesquelles cela est nécessaire. Lorsque rpmbuild parcourt des fichiers .py avec un #! (shebang) il ajoutera automatiquement le binaire que le shebang spécifie comme une exigence. Non seulement cela, si le shebang est #!/usr/bin/env python, il ajoutera une dépendance pour tout ce qui résout (premier python sur $PATH).

Vous devez soit désactiver le traitement automatique des exigences, soit trouver tous les caractères qui causent des problèmes et les changer pour autre chose.

+0

Sons prometteurs - Je vais l'essayer ... – Ilane

+0

>>> imprimer "Merci, F.J !!!" Merci, F.J !!! – Ilane

+1

Vous ne voulez pas désactiver le traitement des dépendances dans ce cas. Cela peut casser le paquetage python car RPM ne saura pas de quoi dépend le fichier. La bonne chose à faire est de patcher le fichier contenant la ligne shebang erronée. – jayhendren

6

rpmbuild peut devenir assez intelligent et c'est l'un de ces cas. Il a probablement tiré la /usr/local/bin/python d'un de vos fichiers de script contenant quelque chose comme:

#!/usr/local/bin/python 

en haut. Essayez de grep pour ce chemin dans les fichiers dans votre fichier bz2.

+0

Il y en a deux - cependant, je ne veux pas gaspiller avec les sources si je n'ai pas à le faire puisque% setup les déballe du fichier téléchargé original - y a-t-il un moyen de contourner ce problème? – Ilane

+1

Ceci est la bonne réponse. Dans le code source python, il y a un fichier avec la ligne shebang contenant '/ usr/local/bin/python'. @Ilane, la bonne chose à faire est d'écrire un patch sur le code source. Une partie standard des RPM de construction consiste à écrire des correctifs.Vous noterez dans le fichier contenant le shebang offensant, il y a un commentaire à l'effet que les packageurs python auront besoin d'écrire un patch s'ils n'installent pas python dans '/ usr/local'. – jayhendren

+1

Plus précisément, le problème est 'cgi.py'. Les spécifications de Fedora ([python 3] (http://pkgs.fedoraproject.org/cgit/python3.git/tree/python3.spec), [python 2] (http://pkgs.fedoraproject.org/cgit/python .git/tree/python.spec)) corrige ce problème en exécutant 'Tools/scripts/pathfix.py'. –

Questions connexes