Spip et sqlite en local avec Mageia6 [Réglé]

Etienne Membre non connecté
-
- Voir le profil du membre Etienne
- Inscrit le : 20/11/2008
- Site internet
- Groupes :
J'ai posé cette question en déterrant un vieux fil de 2014 mais pas de réponse. Je retente en ouvrant un nouveau fil.
Sur une installation en local, Spip ne me propose que mysql alors qu'il devrait me proposer également sqlite.
Les deux paquets php-sqlite3 et phppdo_sqlite sont bien installés.
Y a t-il une configuration particulière à faire ?
Merci,
Etienne

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Citation :
Y a t-il une configuration particulière à faire ?
Je ne pense pas.
j' ai testé une installation de spip, en installant uniquement apache, php_sqlite3 et php_pdosqlite et apache_mod_php ( dans cet ordre) et la page de configuration me propose bien sqlite3 comme moteur de base de donnée.

Etienne Membre non connecté
-
- Voir le profil du membre Etienne
- Inscrit le : 20/11/2008
- Site internet
- Groupes :

Etienne Membre non connecté
-
- Voir le profil du membre Etienne
- Inscrit le : 20/11/2008
- Site internet
- Groupes :
Puis je tente de réinstaller seulement les 4 que tu cites (avec les dépendances obligatoires).
Mais ça bug à l'installation du 4ème (apache_mod_php). Là il m'oblige à installer en dépendance php-suhosin et php-timezonedb. Impossible d'y couper, même en décochant dans les options "sélectionner automatiquement les dépendances".
Or erreur à l'installation, ces deux paquets ne peuvent pas être installés car rendus obsolètes par lib64php_common.
Et si je tente de supprimer ce dernier ça m'oblige à supprimer un tas de choses, dont php-sqlite3.
Ca se mord la queue !

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Est ce qu' il ne pourrait pas y avoir un mix de paquet de différentes versions de php ?
Son mon système, j' ai lib64php5_common,php-suhosin et php-timezonedb qui sont installé simultanément...
Par contre la lib64php_common7-7.2.13 ( qui est dans les backports je pense), rend obsolete un certain nombre de paquets
un petit rpm -qa | grep php permettra peut être de lever ce doute...
Édité par nic80 Le 19/12/2018 à 22h27

Etienne Membre non connecté
-
- Voir le profil du membre Etienne
- Inscrit le : 20/11/2008
- Site internet
- Groupes :
[tieno@localhost ~]$ rpm -qa | grep php
Caché :
php-xml-7.2.13-2.mga6
php-ftp-7.2.13-2.mga6
php-gettext-7.2.13-2.mga6
php-pear-1.10.1-3.mga6
php-xmlwriter-7.2.13-2.mga6
php-imap-7.2.13-2.mga6
lib64php5_common5-5.6.39-1.mga6
php-tokenizer-7.2.13-2.mga6
php-gd-7.2.13-2.mga6
php-sysvshm-7.2.13-2.mga6
php-sqlite3-7.2.13-2.mga6
php-ctype-7.2.13-2.mga6
php-posix-7.2.13-2.mga6
php-xmlreader-7.2.13-2.mga6
php-mysqli-7.2.13-2.mga6
php-mbstring-7.2.13-2.mga6
php-openssl-7.2.13-2.mga6
php-zlib-7.2.13-2.mga6
php-mcrypt-1.0.1-5.mga6
task-lamp-php-3-6.mga6
php-bz2-7.2.13-2.mga6
php-json-7.2.13-2.mga6
php-cli-7.2.13-2.mga6
lib64php_common7-7.2.13-2.mga6
php-pear-File_Iterator-1.3.4-5.mga6
phpmyadmin-4.7.8-3.mga6
php-ini-7.2.13-2.mga6
php-channel-phpunit-1.3-15.mga6
php-sysvsem-7.2.13-2.mga6
php-pdo-7.2.13-2.mga6
php-hash-7.2.13-2.mga6
php-session-7.2.13-2.mga6
php-filter-7.2.13-2.mga6
php-mysqlnd-7.2.13-2.mga6
php-zip-7.2.13-2.mga6
php-dom-7.2.13-2.mga6
apache-mod_php-7.2.13-2.mga6
php-ftp-7.2.13-2.mga6
php-gettext-7.2.13-2.mga6
php-pear-1.10.1-3.mga6
php-xmlwriter-7.2.13-2.mga6
php-imap-7.2.13-2.mga6
lib64php5_common5-5.6.39-1.mga6
php-tokenizer-7.2.13-2.mga6
php-gd-7.2.13-2.mga6
php-sysvshm-7.2.13-2.mga6
php-sqlite3-7.2.13-2.mga6
php-ctype-7.2.13-2.mga6
php-posix-7.2.13-2.mga6
php-xmlreader-7.2.13-2.mga6
php-mysqli-7.2.13-2.mga6
php-mbstring-7.2.13-2.mga6
php-openssl-7.2.13-2.mga6
php-zlib-7.2.13-2.mga6
php-mcrypt-1.0.1-5.mga6
task-lamp-php-3-6.mga6
php-bz2-7.2.13-2.mga6
php-json-7.2.13-2.mga6
php-cli-7.2.13-2.mga6
lib64php_common7-7.2.13-2.mga6
php-pear-File_Iterator-1.3.4-5.mga6
phpmyadmin-4.7.8-3.mga6
php-ini-7.2.13-2.mga6
php-channel-phpunit-1.3-15.mga6
php-sysvsem-7.2.13-2.mga6
php-pdo-7.2.13-2.mga6
php-hash-7.2.13-2.mga6
php-session-7.2.13-2.mga6
php-filter-7.2.13-2.mga6
php-mysqlnd-7.2.13-2.mga6
php-zip-7.2.13-2.mga6
php-dom-7.2.13-2.mga6
apache-mod_php-7.2.13-2.mga6
lib64php5_common n'était effectivement pas installé. Mais ne change rien.
lib64php_common7 ne provient pas des backports, qui ne sont pas installés. Comment je pourrais faire pour interdire son installation (si tant est que le problème vienne de là ?)

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je ne suis pas sur que mélanger version 5 et 7 de php (j' aurais tendance à penser que lib64php5 est pour du php5 ( en l' occurence php 5.6.39) et que la lib64php_common7 serait plus pour la version 7.2.13).
Dans la liste, je ne vois pas de php-pdo_sqlite-7.2.13-2.mga6. C' est normal ?
edit: sur cette page, il est indiqué que pour SQLite 3, Spip utilise pdo et pdo_sqlite.
Édité par nic80 Le 22/12/2018 à 18h47

Etienne Membre non connecté
-
- Voir le profil du membre Etienne
- Inscrit le : 20/11/2008
- Site internet
- Groupes :
En reproduisant la manoeuvre de virer tous les paquets apache, mysql, sqlite etc... et de réinstaller seulement apache, php-sqlite3 et php-pdosqlite, php-pdo et apache-mod_php, mais cette fois pas par le CCM mais en console urmpi.
En installant en console, les dépendances imposées sont bien moins nombreuses et plus cohérentes en versions que via le CCM (genre ça m'installe 5 ou 6 dépendances au lieu de 40. Et je n'ai plus le problème de conflits de dépendances.
En fait je pensais que le CCM était une interface graphique pour urpmi, mais apparemment ça fonctionne très différemment.
Merci de vos aides,
Etienne

magnux77 Membre non connecté
-
- Voir le profil du membre magnux77
- Inscrit le : 21/09/2009
- Groupes :
-
Membre d'Honneur
Etienne :
En fait je pensais que le CCM était une interface graphique pour urpmi, mais apparemment ça fonctionne très différemment.
Cette déduction d'Étienne mériterait infirmation ou confirmation de la part de nos experts.
Messieurs ?
Is it fake news ?
...depuis Mandrake 7
Membre de l'April - « promouvoir et défendre le Logiciel Libre»
Soutien Framasoft - « Changer le monde, un octet à la fois»
Config n°1 : cpu=AMD64x6 mem=16G SSD=64G HDD=1T OS=Mageia8-64 DE=Xfce, Config n°2 : Dell Latitude E6410 SSD=120G OS=Mageia8 DE=Xfce, Config n°3 : ThinkpadR40 SSD=32G OS=[Manjaro, Parabola, Mageia6] DE=Xfce, Config n°4 : EeePC901 SSD=20Gb, OS=[SliTaz5/Lxde, Mageia8/Xfce]
Membre de l'April - « promouvoir et défendre le Logiciel Libre»
Soutien Framasoft - « Changer le monde, un octet à la fois»
Config n°1 : cpu=AMD64x6 mem=16G SSD=64G HDD=1T OS=Mageia8-64 DE=Xfce, Config n°2 : Dell Latitude E6410 SSD=120G OS=Mageia8 DE=Xfce, Config n°3 : ThinkpadR40 SSD=32G OS=[Manjaro, Parabola, Mageia6] DE=Xfce, Config n°4 : EeePC901 SSD=20Gb, OS=[SliTaz5/Lxde, Mageia8/Xfce]

choucroot Membre non connecté
-
- Voir le profil du membre choucroot
- Inscrit le : 07/08/2015
- Groupes :

Sur ce , de bonnes fêtes à tous ...
Ordinateurs : Mageia9 64bits XFCE: MSI Cubi N-8GL-002BEU (Pentium N5000), NUC11ATKPE (Pentium N6005), HP ELITEBOOK 820-G3 (I5-6200U)
Smartphone: /e/OS ( Samsung S7 Edge )
Smartphone: /e/OS ( Samsung S7 Edge )

stroibe974 Membre non connecté
-
- Voir le profil du membre stroibe974
- Inscrit le : 13/08/2018
- Groupes :
-
Modérateur
Etienne :
Bon, résolu.
En reproduisant la manoeuvre de virer tous les paquets apache, mysql, sqlite etc... et de réinstaller seulement apache, php-sqlite3 et php-pdosqlite, php-pdo et apache-mod_php, mais cette fois pas par le CCM mais en console urmpi.
En installant en console, les dépendances imposées sont bien moins nombreuses et plus cohérentes en versions que via le CCM (genre ça m'installe 5 ou 6 dépendances au lieu de 40. Et je n'ai plus le problème de conflits de dépendances.
En reproduisant la manoeuvre de virer tous les paquets apache, mysql, sqlite etc... et de réinstaller seulement apache, php-sqlite3 et php-pdosqlite, php-pdo et apache-mod_php, mais cette fois pas par le CCM mais en console urmpi.
En installant en console, les dépendances imposées sont bien moins nombreuses et plus cohérentes en versions que via le CCM (genre ça m'installe 5 ou 6 dépendances au lieu de 40. Et je n'ai plus le problème de conflits de dépendances.
Je pense que la différence vient du fait que les dépendances ont déjà été installées... En effet, quand tu désinstalles les paquets, les dépendances ne sont pas automatiquement supprimées : elles sont inscrites dans une liste « orphans » (vous savez, la fameuse commande urpme --auto-orphans qu'il faut manier avec beaucoup de précautions...) et vous pouvez les supprimer si vous êtes sûr de votre coup.
Etienne :
En fait je pensais que le CCM était une interface graphique pour urpmi, mais apparemment ça fonctionne très différemment.
En fait je pensais que le CCM était une interface graphique pour urpmi, mais apparemment ça fonctionne très différemment.
En fait, le CCM c'est l'ensemble qui contient le Gestionnaire de logiciels (interface pour urpmi, effectivement), les outils de configuration du matériel, Réseau et internet, Système, Partage réseau, Disques locaux, Sécurité et Démarrage.
Édité par stroibe974 Le 23/12/2018 à 20h45

Etienne Membre non connecté
-
- Voir le profil du membre Etienne
- Inscrit le : 20/11/2008
- Site internet
- Groupes :
Le CCM ne réagit pas comme urpmi.
Je refais la manip : je supprime par le CCM tout ce qui contient php, sqlite, apache, mysql (à condition que ça ne m'oblige pas à supprimer des logiciels). Je ne fais pas d'auto-orphans. Puis je réinstalle les paquets. Chaque fois je vérifie ce que me propose le CCM avant d'installer en urpmi.
apache : le CCM me propose deux versions (2.4.26 ou 2.4.37), urpmi installe d'office la 2.4.37.
php-sqlite3 : le CCm propose à nouveau 2 versions (5.6.30 et 5.6.39), mais surtout, quelle que soit la version choisie, impose d'installer plein de dépendances, parmi lesquelles la fameuse lib64php_common7 qui me bloquait par la suite :
Caché :
- lib64php5_common5-5.6.39-1.mga6.x86_64
- lib64php_common7-7.2.13-2.mga6.x86_64
- php-cgi-7.2.13-2.mga6.x86_64
- php-ctype-7.2.13-2.mga6.x86_64
- php-dom-7.2.13-2.mga6.x86_64
- php-filter-7.2.13-2.mga6.x86_64
- php-ftp-7.2.13-2.mga6.x86_64
- php-gettext-7.2.13-2.mga6.x86_64
- php-hash-7.2.13-2.mga6.x86_64
- php-ini-7.2.13-2.mga6.x86_64
- php-json-7.2.13-2.mga6.x86_64
- php-openssl-7.2.13-2.mga6.x86_64
- php-pdo-7.2.13-2.mga6.x86_64
- php-posix-7.2.13-2.mga6.x86_64
- php-session-7.2.13-2.mga6.x86_64
- php-sysvsem-7.2.13-2.mga6.x86_64
- php-sysvshm-7.2.13-2.mga6.x86_64
- php-tokenizer-7.2.13-2.mga6.x86_64
- php-xml-7.2.13-2.mga6.x86_64
- php-xmlreader-7.2.13-2.mga6.x86_64
- php-xmlwriter-7.2.13-2.mga6.x86_64
- php-zlib-7.2.13-2.mga6.x86_64
- lib64php_common7-7.2.13-2.mga6.x86_64
- php-cgi-7.2.13-2.mga6.x86_64
- php-ctype-7.2.13-2.mga6.x86_64
- php-dom-7.2.13-2.mga6.x86_64
- php-filter-7.2.13-2.mga6.x86_64
- php-ftp-7.2.13-2.mga6.x86_64
- php-gettext-7.2.13-2.mga6.x86_64
- php-hash-7.2.13-2.mga6.x86_64
- php-ini-7.2.13-2.mga6.x86_64
- php-json-7.2.13-2.mga6.x86_64
- php-openssl-7.2.13-2.mga6.x86_64
- php-pdo-7.2.13-2.mga6.x86_64
- php-posix-7.2.13-2.mga6.x86_64
- php-session-7.2.13-2.mga6.x86_64
- php-sysvsem-7.2.13-2.mga6.x86_64
- php-sysvshm-7.2.13-2.mga6.x86_64
- php-tokenizer-7.2.13-2.mga6.x86_64
- php-xml-7.2.13-2.mga6.x86_64
- php-xmlreader-7.2.13-2.mga6.x86_64
- php-xmlwriter-7.2.13-2.mga6.x86_64
- php-zlib-7.2.13-2.mga6.x86_64
Alors que urpmi php-sqlite3 n'installe que deux autres paquets :
Caché :
(média « Core Updates »)
lib64php5_common5 5.6.39 1.mga6 x86_64
php-pdo 5.6.39 1.mga6 x86_64
php-sqlite3 5.6.39 1.mga6 x86_64
lib64php5_common5 5.6.39 1.mga6 x86_64
php-pdo 5.6.39 1.mga6 x86_64
php-sqlite3 5.6.39 1.mga6 x86_64
php-pdo_sqlite : CCM propose là aussi deux versions (5.6.30 et 5.6.39). N'impose pas de dépendances.
apache-mod_php : là carrément le CCM ne veut pas, quelle que soit la version choisie (5.6.30 u 5.6.39) :
Caché :
Désolé, le paquetage suivant ne peut pas être sélectionné :
- apache-mod_php-5.6.39-1.mga6.x86_64 (car php-timezonedb[>= 3:2012.3] est non satisfait)
- apache-mod_php-5.6.39-1.mga6.x86_64 (car php-timezonedb[>= 3:2012.3] est non satisfait)
alors que urpmi apache-mod_php
Caché :
Pour satisfaire les dépendances, les paquetages suivants vont être installés :
Paquetage Version Révision Arch
(média « Core Release2 »)
php-suhosin 0.9.38 1.mga6 x86_64 (recommandé)
php-timezonedb 2017.2 1.mga6 x86_64
(média « Core Updates »)
apache-mod_php 5.6.39 1.mga6 x86_64
php-ctype 5.6.39 1.mga6 x86_64
php-dom 5.6.39 1.mga6 x86_64
php-filter 5.6.39 1.mga6 x86_64
php-ftp 5.6.39 1.mga6 x86_64
php-gettext 5.6.39 1.mga6 x86_64
php-hash 5.6.39 1.mga6 x86_64
php-ini 5.6.39 1.mga6 x86_64
php-json 5.6.39 1.mga6 x86_64
php-openssl 5.6.39 1.mga6 x86_64
php-posix 5.6.39 1.mga6 x86_64
php-session 5.6.39 1.mga6 x86_64
php-sysvsem 5.6.39 1.mga6 x86_64
php-sysvshm 5.6.39 1.mga6 x86_64
php-tokenizer 5.6.39 1.mga6 x86_64
php-xml 5.6.39 1.mga6 x86_64
php-xmlreader 5.6.39 1.mga6 x86_64
php-xmlwriter 5.6.39 1.mga6 x86_64
php-zlib 5.6.39 1.mga6 x86_64
un espace additionnel de 3.1Mo sera utilisé.
944Ko de paquets seront récupérés.
Procéder à l'installation des 21 paquetages ? (O/n)
Paquetage Version Révision Arch
(média « Core Release2 »)
php-suhosin 0.9.38 1.mga6 x86_64 (recommandé)
php-timezonedb 2017.2 1.mga6 x86_64
(média « Core Updates »)
apache-mod_php 5.6.39 1.mga6 x86_64
php-ctype 5.6.39 1.mga6 x86_64
php-dom 5.6.39 1.mga6 x86_64
php-filter 5.6.39 1.mga6 x86_64
php-ftp 5.6.39 1.mga6 x86_64
php-gettext 5.6.39 1.mga6 x86_64
php-hash 5.6.39 1.mga6 x86_64
php-ini 5.6.39 1.mga6 x86_64
php-json 5.6.39 1.mga6 x86_64
php-openssl 5.6.39 1.mga6 x86_64
php-posix 5.6.39 1.mga6 x86_64
php-session 5.6.39 1.mga6 x86_64
php-sysvsem 5.6.39 1.mga6 x86_64
php-sysvshm 5.6.39 1.mga6 x86_64
php-tokenizer 5.6.39 1.mga6 x86_64
php-xml 5.6.39 1.mga6 x86_64
php-xmlreader 5.6.39 1.mga6 x86_64
php-xmlwriter 5.6.39 1.mga6 x86_64
php-zlib 5.6.39 1.mga6 x86_64
un espace additionnel de 3.1Mo sera utilisé.
944Ko de paquets seront récupérés.
Procéder à l'installation des 21 paquetages ? (O/n)
Donc j'en conclu que le CCM n'est pas réellement une interface pour urpmi. Il fonctionne différemment et dans le cas présent j'avais beau essayer dans tous les sens, installer les paquets en changeant l'odre, ça bloquait tout le temps quelque part et je n'avais pas moyen de faire fonctionner sqlite en local.
Bon, il y peut-être des explications que je maitrise pas ...
Bonnes fêtes,
Édité par Etienne Le 24/12/2018 à 10h52
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie