problème avec mysql FC3!

Salut!

Je viens d'installer MySQL 4.1 sur mon FC3 machine. Parce qu'il a donné quelques erreurs de vague avec la sortie standard disponibles, j'ai décidé d'installer à partir de l'archive source. Donc, j'ai réussi à l'installer, avec php et également apache (tous compilés à partir des sources). Maintenant, la raison, je fait tout cela était d'obtenir le Midgard CMS en cours d'exécution http://www.midgardproject.org Maintenant, quand j'ai essayé d'installer le rpm pour cela, il donne l'erreur suivante


Je ne comprends pas pourquoi ce qui se passe. Maintenant, j'ai aussi vérifié et constaté que le démon MySQL était en marche. Mais de toute façon, Midgard n'est tout simplement pas le reconnaître. Somebody Help Me s'il vous plaît.

Merci à l'avance.

Juma

PS: S'il vous plaît ne suggèrent pas d'autre système CMS, parce que ce truc je suis en train de construire est partie d'un autre site, qui est sur Midgard et si je dois me servir Midgard.

Plus que probablement, à la bibliothèque que le RPM Midgard pour les besoins ne sont pas installés, au lieu que vous avez installé une nouvelle bibliothèque.

Parce que vous avez pris le temps d'installer la source - une bonne idée - vous avez sauté une rev pour mysql. Le RPM est à la recherche de 3.x ou d'une «plus grande», et vous avez installé 4.x. Je suppose que vous avez dans votre lib dir libmysqlclient.so.14 ou de quelque chose. (Run a trouver la commande en tant que root, repérez la bibliothèque sans le numéro - pari son supérieur).

Est-ce qu'ils proposent en tant que source Midgard? Essayez-le en tant que tel, le cas échéant.

Si non, vous avez besoin de mai, soit de retour à la rev mysql rpm, le paquet Midgard attend ou certains lourds de levage et de manipuler, soit ce que le régime est à la recherche, ou à ce que sa recherche.

Tout d'abord, merci d'une tonne pour votre aide. Vous avez eu raison, en fait il a été libmysqlclient14 seulement. Maintenant, j'ai un problème nouveau, mais à peu près du même genre. J'ai essayé d'installer Midgard partir des sources. Cette Midgard doit également glib> 2.4. J'ai un RPM par défaut, qui vient FC3, ce qui est de 1,2. J'ai essayé obtenir un RPM pour elle, si le script de configuration de Midgard détecte cette version plus tard, mais je n'arrive pas à le trouver nulle part. Alors, j'ai essayé d'installer glib de source, mais Midgard ne détecte pas cette version de glib du tout. Lorsque j'ai couru à configurer avec l'aide c'est ce que je reçois



Alors, j'ai essayé de trouver ce script de configuration de glib, mais ne la trouva nulle part. Je pouvais seulement trouver un fichier taglib-config, que je ne suis pas sûr est encore lié à glib.
Donc, u anychance savoir où le script de configuration glib est-ce? J'ai essayé la lecture des docs glib, mais n'a pas pu le trouver. Ou comment puis-je dire à ce script de configuration de Midgard à la recherche de glib / glib??

Vous auriez eu la même chose si vous aviez réussi à mettre à jour de la RPM.

Vous avez besoin de la mysqlclient10-3,23 RPM. Il a été construit juste à cause de ce problème.

il fournit les éléments suivants (dans / usr / lib [64] / mysql / répertoire):
libmysqlclient_r.so.10
libmysqlclient_r.so.10.0.0
libmysqlclient.so.10
libmysqlclient.so.10.0.0


EDIT: désolé, l'a été au-dessus de votre mysql question.

Sur un système basé sur RPM, vous devriez vraiment pas l'installer à partir de la source, sauf si vous n'avez pas d'autre option, btw.

En remarque, pourquoi ne pas simplement la mise à niveau vers FC4?

Je suis entièrement d'accord, je préfère toujours à construire à partir des sources si l'unité est d'être une plate-forme serveur.
Theres presque toujours les problèmes de dépendances circulaires pesky avec RPM et les "disparus" de bibliothèques. La raison en est que d'un RPM générique est une distribution binaire, et en tant que tel est forcé de faire certaines hypothèses.
Dans les entreprises, les hypothèses peuvent être dévastateurs. La seule fois que je défends leur utilisation lorsque le régime est lui-même est conçu à l'interne et ne contient que ce que nous jugeons nécessaires. Il s'agit bien sûr, après avoir construit à partir de sa source.
Theres beaucoup trop de fragmentation dans le processus de construction du RPM pour couvrir toutes les situations - nous nous retrouvons avec patchware binaire, à la Microsoft. Yay.
Ensuite, nous pourrions parler de l'ensemble de la stabilité jihad. Ou nous pourrions Etat, que tout ce qui est construit en natif a de bien meilleures chances d'être stable - programmation simple, 101.

Néanmoins, il finit par être moins à la source des maux de tête bâtiment que quelqu'un elses générique paquetage RPM. Cela étant dit, une fois que vous démarrez la pente, de sa difficile de faire votre chemin de retour. Son séduisant et simple. Jusqu'à ce que vous en plein la tête dans un mur de briques, ses même agréable.
Par moments, vous mai même pas d'autre choix en la matière.

La principale raison je préconise l'utilisation de RPM sur un système basé sur RPM traite de la gestion du système. L'ensemble du problème de dépendance est presque chose du passé avec des utilitaires comme up2date et yum. L'utilisation de ces services supprime également certains des facteurs d'erreur humaine lors de l'installation ou la mise à jour des paquets installés sur le système.

En ce qui concerne la stabilité, si vous êtes assez intelligent pour faire plus que simplement
. / configure
make & & make install
qui, si vous êtes désireux de l'installer à partir de la source sur un système basé sur RPM, je suppose que vous serait, alors vous êtes probablement assez intelligent pour télécharger le paquet RPM et ainsi générer votre propre système rpm spécifique pour ce système - qui ne vous donnent la flexibilité de l'installation de la source, tout en ayant la possibilité de mettre à jour que paquet (ou supprimer) avec un utilitaire comme une de celles ci-dessus.

Just my 2 ¢ - nous savons tous les deux theres débat sur l'internet tous sur ce sujet.