Ceci dit, faut pas s'emballer, ce n'est pas encore tout de suite, pour moi en tout cas, que VirtualBox ou Vym vont ressembler à cela. Car pour l'instant je n'ai juste pas réussi à le compiler. En effet ce code est seulement compatible avec la version 4 de Qt, et même avec la version 4.4 pour être exact, ce qui semble être la cause de mon blocage avec Mandriva qui n'a pour l'instant que la 4.3 en réserve.
Encore un peu d'attente donc pour voir si le projet continue à vivre (car ce n'est pas toujours le cas chez trolltech). En tout cas, l'idée est suffisamment bonne et le rendu suffisamment prometteur pour être relevé.
]]>
Pour l'utiliser, il suffit d'ajouter le filtre dans l'administration drupal et de l'utiliser de la manière suivante: encadrer le code à colorer avec les balises
<code type="java" caption="un titre">
Votre code
</code>
Je n'avais pas pensé à l'origine que ce code puisse intéresser certains. Il est donc tout vilain à l'intérieur 
Dés que j'aurais le temps, j'y mettrais un grand coup de propre.
En effet, à l'heure où les plateforme de Applications Internet Riche (RIA) se multiplient comme des petits pains (PRISM, AIR, SilverLight, JavaFX, etc.), Adobe s'est donné les moyens de rendre son lecteur le plus universel possible. C'est du coup la première fois qu'un version du lecteur sort en même temps pour MacOS, Windows ET Linux. Ce fait en lui-même est un événement qui prouve que la plateforme libre devient de moins en moins contournable.
Autre aspect majeur, cette version 10 est en réalité la première d'une nouvelle génération suivant les spécification de l'Open Screen Project.
Ce projet vise à définir une plateforme ouverte d'Application Internet Riche basée sur les formats d'Adobe. Il est soutenu entre autre par Motorola, Intel, LG Electronics et peut être résumé par les points suivants :
Il n'y a donc pas à ma connaissance d'ouverture des sources des lecteur eux-mêmes mais malgré cela, cette initiative devrait rapidement être profitable à gnash , le lecteur libre, qui pour l'heure est d'une stabilité plus que moyenne.
Il ne reste maintenant plus qu'à tester ce nouveau lecteur qui au delà de ce qui vient d'être dit, affiche tout de même une liste impressionnante de nouveautés.
]]>Mais malgré cette richesse, il arrive parfois que l’on ne trouve pas LE module « qui va bien ». Alors pourquoi ne pas le fabriquer soi-même et ainsi découvrir à quel point Drupal s'adapte facilement à des besoins spécifiques.
]]>Mais malgré cette richesse, il arrive parfois que l’on ne trouve pas LE module « qui va bien ». Alors pourquoi ne pas le fabriquer soi-même et ainsi découvrir à quel point Drupal s'adapte facilement à des besoins spécifiques.
Les prérequis pour développer un module sont évidemment une bonne connaissance des concepts clés de Drupal (node, type de contenu, taxonomy, etc.), une relative maîtrise de PHP et quelques bases en SQL. Armé de tout cela, nous allons dans ce tutoriel chercher à construire un module permettant de gérer une simple liste de courses. Il s'agira en quelque sorte de la version moderne du tableau sur le réfrigérateur, amélioré d'une petite gestion des réserves. Le module permettra :
Avant de poursuivre, il est important de comprendre ce qu'est réellement un module. Un module Drupal est un bout de code PHP que l'on peut activer ou désactiver, et qui implémente des "hooks".
Un hook (en français, "Crochet") est un prototype de fonction dédié à une tâche spécifique, comme par exemple mettre en forme le contenu d'un node avant affichage. Chaque module peut ainsi implémenter ce hook sous la forme d'une fonction ayant des paramètres calqués sur ceux du prototype. Dans le cas de la mise en forme, le prototype se nomme hook_view:
prototype du hook 'hook_view'function hook_view($node, $teaser = FALSE, $page = FALSE)
Ainsi un module désirant implémenter ce hook, devra comporter le code suivant :
Lorsque Drupal aura besoin de mettre en forme un node, il cherchera dans la liste de toutes les fonctions PHP disponibles, c'est-à-dire les fonctions contenues dans tous les modules activés, thèmes compris, celles dont le nom commence par le nom d'un module et se termine par _view, le nom du hook.
Ensuite, Drupal va appeler les fonctions les unes après les autres et chacune d'entre elles va modifier l'objet $node passé en paramètre.
Le hook hook_view est défini et utilisé par le module modules/node.module fournis en standard. Nous comprenons ainsi que tous les modules peuvent proposer leur propre hook pour permettre à d'autres modules de prendre en charge un traitement spécifique. Pour avoir la liste des hooks fournis par un module, il faut se reporter à sa documentation. Dans le cas spécifique des modules fournis en standard dans Drupal (node, book, etc), vous trouverez leur description dans la documentation de l'API Drupal. Bien l'étudier est important car chaque hook a son propre fonctionnement. Certains s'attendent à ce que le contenu de l'objet passé en paramètre soit modifié, d'autres qu'un tableau soit renvoyé par la fonction, etc.
Un module est donc un fournisseur d'implémentations de hooks. En conséquence, la majeure partie de son code va s'insérer dans les traitements de Drupal et en étendre le comportement. Maintenant de manière plus prosaïque, un module est simplement un dossier qui contient au minimum deux fichiers.
Ce dossier doit porter le nom du module et doit être placé dans l'arborescence de Drupal, à un endroit qui soit approprié pour que ce dernier puisse le voir. Techniquement il est possible de les mettre dans modules/ mais vous seriez vite embêtés lors d'un changement de version. Il est donc préconisé de mettre cela dans un dossier sites/all/modules/mes_modules que vous créerez si nécessaire. Ainsi lorsque vous changez de version, il suffit de déplacer le dossier sites à sa place dans la nouvelle arborescence.
Dans ce dossier mes_modules, vous allez donc créer le sous-dossier du module lui-même, dans notre cas courses. A l'intérieur de celui-ci, vous devez avoir au minimum deux fichiers, portant le même nom de base que le dossier parent : courses.info et courses.module. Ce qui nous donne l'arborescence suivante :
Le fichier courses.info est un simple fichier texte contenant des informations sur le module comme son nom, sa description, la version de Drupal avec lequel il est compatible, etc. Ce qui nous donne pour notre exemple, le contenu suivant :
Le second fichier est le code PHP du module. C'est lui qui va héberger les hooks que nous souhaitons implémenter. Pour l'instant, nous allons faire simple et n'en mettre aucun. Notre fichier va donc contenir une simple balise de démarrage de code PHP :
A ce stade nous pourrions déjà activer notre module, mais ne le faites pas tout de suite, nous avons encore quelque chose à rajouter.
Notre module courses a pour finalité de pouvoir saisir des produits et de les présenter sous la forme d'une liste. Nous pourrions pour cela utiliser un type de contenu simple comme story mais cette structure de stockage serait trop limitée car nous avons des informations plus précises à saisir que les seuls titre et corps. Il nous faut en effet spécifier le nombre de produits restants et le nombre minimum à avoir en réserve pour pouvoir générer notre liste de courses. Nous allons donc créer un nouveau type de node, produit, en cherchant à étendre le type de node simple.
Drupal stocke les données de base d'un node (titre, corps, etc.) dans la table node dont la clef primaire est le champ nid. Ce sont les valeurs de ce champ que vous retrouvez dans l'URL d'un node, sous la forme http://mon_site_drupal?q=/node/1234. Elle dispose aussi d'un champ type de type texte identifie le type du contenu. Dans notre cas ce type prendra la valeur produit.
Mais pour stocker nos informations supplémentaires, nous allons devoir créer une nouvelle table, traditionnellement nommée node_produit, contenant un champ quantité pour la quantité restante du produit et un champ seuil pour la valeur minimum à conserver en réserve. En outre elle disposera, elle aussi, d'un champ nid. Les informations sur un produit donné seront donc réparties sur les champs des deux tables à la fois (node et node_produit)reliées entre-elles par le même nid.
Du coup, pour obtenir toutes les informations disponibles sur un node de type produit, nous pouvons formuler la requête suivante :
Alors nous pourrions évidemment créer cette nouvelle table à la main mais ce serait bien peu pratique lorsque viendra le moment de redistribuer ce module. La bonne pratique est donc de déléguer ce travail à Drupal lors de l'activation du module. De la même manière, nous allons lui indiquer comment la supprimer, lorsque le module est désactivé puis désinstallé.
Pour ce faire, il nous faut rajouter un troisième fichier à notre dossier module : courses.install qui va contenir deux hooks. Le premier, hook_install, est invoqué lors de la première activation du module (installation). Le second, hook_uninstall, est quant à lui invoqué lors de la désinstallation du module.
Le code n'a rien de compliqué mais quelques points cependant méritent éclaircissement.
Tout d'abord, nous distinguons deux cas qui correspondent aux deux bases de données prises en charge par Drupal : mySQL et PostgreSQL. En effet, si les bases de données sont à peu près équivalentes s'agissant des requêtes INSERT,DELETE,UPDATE et SELECT, c'est un peu moins le cas pour les commandes CREATE et ALTER.
Ensuite concernant l'exécution des requêtes SQL, nous devons à tout prix éviter d'utiliser les fonctions base de données de PHP au profit de celles fournies par Drupal. En effet ces dernières présentent l'avantage de faire abstraction de la base de données sous-jacente.
Dans le cas spécifique de l'installation et de la désinstallation, nous utilisons update_sql mais pour le reste du code elle sera remplacée par db_query. Ces deux fonctions sont pratiquement identiques à la différence près qu'update_sql fournit plus d'informations sur le déroulement de la requête. Informations qui seront utilisées par l'assistant d'installation et de mise à jour de Drupal.
Dernier point : les accolades utilisées pour encadrer le nom des tables. Elles ne sont pas nécessaires mais permettent à Drupal certaines opérations de préparation des requêtes. C'est donc juste une bonne habitude à prendre.
Maintenant que notre installation est finalisée, il ne nous reste plus qu'à activer notre module dans le panneau d'administration de Drupal : http://mon_site_drupal?q=/admin/build/modules. Une fois cette opération achevée, vous pouvez vérifier à l'aide de votre explorateur de base de données préféré que la table node_produit a bel et bien été créée. Si vous désactivez et réactivez votre module, notez que le code d'installation n'est pas ré-exécuté. En effet, il vous faut d'abord désinstaller le module, pour que le hook courses_uninstall soit appelé et détruise la table. Ensuite, si vous réactivez à nouveau le module, la table sera recréée.
Notre base est prête, notre module activé et pourtant si nous ouvrons l'URL http://mon_site_drupal/?q=node/add, notre produit n'apparaît pas. En effet, il faut implémenter deux hooks dans le fichier courses.module pour indiquer à Drupal qu'un nouveau type de node est à prendre en charge. Le premier hook, hook_node_info, va décrire le nouveau type de node :
Ce hook renvoie le tableau associatif de types de contenu et de leur description. Mais ici nous n'en renvoyons qu'un seul, produit, avec sa description et son nom usuel. L'identifiant produit sera utilisé dans la colonne type de la table node comme vu au chapitre précédent. Notez enfin l'utilisation de la fonction t(...) qui permet à Drupal de prendre en charge les éventuelles traductions de la phrase en paramètre. Là aussi, utiliser systématique cette fonction pour tous les textes est une bonne habitude à prendre.
Enfin, ke dernier paramètre est le nom du module qui va gérer ce type de contenu, en l'occurrence, notre module courses<.kbd>.
Une dernière étape est nécessaire pour pouvoir disposer de notre nouveau type de contenu : mettre en place le formulaire de saisie. Mais avant cela, il est important de bien comprendre comment Drupal fait vivre un node à travers l'objet $node.
En effet, nombre de hooks prennent en paramètre un objet $node. Cet objet représente comme on peut se l'imaginer, le node en cours de traitement par Drupal. Au fur et à mesure de l'avancement de ce traitement, les différents hooks enrichissent l'objet $node jusqu'à y ajouter le code HTML qui sera finalement inséré dans la page. C'est ainsi que dans le template node.tpl.php l'affichage du titre passe par une référence à $node->title.
Il existe une relation étroite entre l'objet $node et sa représentation en base de donnée. Si le node existe déjà, Drupal initialise l'objet $node en remontant la ligne correspondant au nid recherché. L'objet reçoit ainsi tous les champs de la table node sous la forme d'attributs dont l'intitulé est le nom de la colonne et la valeur, celle qui se trouve en base. Lorsque le node n'existe pas encore, Drupal crée simplement un objet vide. C'est donc soit l'objet vide, soit l'objet chargé des valeurs de la base, que nous allons récupérer dans le hook qui va créer notre formulaire : hook_form.
Ce hook est chargé de transférer les valeurs du node passé en paramètre aux champs d'un formulaire qui sera affiché sur le navigateur client. Ce formulaire sera utilisé pour un $node vide si l'on cherche à créer un nouveau node, mais aussi sur un node "chargé" dans le cas contraire.
Un formulaire Drupal est en pratique un simple tableau associatif. Chaque entrée de ce tableau correspond à un champ du formulaire. Chaque champ est lui-même un tableau associant une propriété du champ à sa valeur. Une liste des types de champs et propriétés associées est disponible dans la documentation de Drupal.
La propriété vraiment intéressante ici est #default_value, car c'est elle qui va permettre d'extraire de $node, les valeurs de champs que le formulaire doit permettre de modifier. Lorsque l'utilisateur validera le formulaire, Drupal se chargera de réintégrer automatiquement les valeurs saisies dans l'objet $node. C'est pour cela que l'identifiant du champ est le même que celui de l'attribut correspondant dans $node ($form['quantite'] et $node->quantite).
Comme nous l'avons vu plus haut, l'objet $node est vide à sa création. Si l'on utilise donc notre formulaire tel quel, les champs quantité et seuil vont l'être aussi. Il est donc nécessaire d'implémenter un nouveau hook, hook_prepare, qui comme son nom l'indique, a pour rôle de préparer l'objet $nodeavant utilisation dans le formulaire.
Grâce à cette fonction, nous initialisons notre objet $node avec les bonnes valeurs par défaut. De la même manière nous pouvons valider ce que renvoie le formulaire en implémentant cette fois hook_validate
Comme cela a déjà été dit, chaque hook a son propre mode opératoire. A hook_load est passé en paramètre un objet $node contenant déjà les informations extraites de la table node. Cela inclut donc la valeur du nid que nous utilisons dans notre requête pour lire en base nos valeurs supplémentaires. L'objet ainsi formé est renvoyé par l'implémentation du hook pour être agrégé par Drupal à l'objet $node.
db_query, dont nous parlions plus haut, renvoie un curseur sur le résultat de la requête qu'elle vient d'exécuter. Elle autorise l'utilisation des motifs %d et %s comme la fonction PHP sprintf. Cela nous permet d'éviter d'encombrer la requête et ainsi gagner en lisibilité.
Notez enfin que db_query ne va pas insérer de guillemets atours des chaînes. C'est donc à vous de mettre des '%s'. En revanche, elle se charge de l'échappement des caractères spéciaux vous protégeant des injections de code SQL malicieux.
Enfin, la fonction Drupal db_fetch_object va, comme son nom le suggère, lire un enregistrement enregistrement à partir du curseur renvoyé par db_query et transformer le résultat en un objet PHP.
Voilà qui est terminé pour le chargement des données de notre nouveau type de node. Voyons maintenant comment insérer, mettre à jour ou encore détruire nos données supplémentaires en implémentant respectivement hook_insert, hook_update et hook_delete :
Nous pouvons maintenant utiliser notre nouveau type de contenu. Vous pouvez ainsi créer un nouveau produit, saisir ses valeurs, le sauvegarder, le modifier, et le détruire.
La première chose que l'on constate cependant est que les informations affichées lorsque l'on vient de créer un node sont loin d'être complètes. En effet la vue sur le node ne donne aucune indication sur la quantité ou le seuil de rachat du produit. Pour changer cela, nous allons implémenter un nouveau hook, hook_view, et une fonction de thème.
Notre hook a ici pour objectif d'ajouter des sections d'informations supplémentaires avant l'affichage réel du node. Pour cela nous préparons le node à l'affichage par la fonction node_prepare. Cette fonction entre autre tâche, applique les filtres d'entrée, fabriquer le teaser s'il n'existe pas encore.
Une fois le node préparé, nous vérifions que le contexte dans lequel nous sommes appelé. En effet, nous n'allons ajouter nos informations supplémentaires que dans le cas où Drupal cherche à afficher le node en pleine page ($page==TRUE). Si c'est juste pour une liste ou un teaser, on laisse l'affichage par défaut.
L'ajout d'information se fait par l'insertion dans le tableau associatif $node->content des données HTML à afficher. Chaque entrée de ce tableau forme ainsi des sections que l'on peut ordonner grâce à la propriété #weight. La propriété #value contiendra le texte lui-même.
Pour renseigner #value nous rajoutons une petite finesse : l'utilisation d'une fonction de thème theme('courses_view', $node). Cela consiste à demander à Drupal d'habiller l'objet $node avec le thème courses_view. La fonction en interne va procéder de la manière suivante :
Une bonne pratique est donc de toujours fournir un thème par défaut en utilisant ce dernier cas de figure. Ainsi, Drupal trouver toujours de quoi habiller notre node tout en laissant à vos utilisateurs la possibilité de changer cet habillage. Là aussi c'est une bonne pratique à garder à l'esprit.
Vous aurez sans doute remarqué que chaque node disposent, à la fin du texte (teaser ou page), d'une série de liens qui offrent des actions qui lui sont propres. Ces liens sont définis grâce à l'implémentation de hook_view. Nous allons donc utiliser cette fonctionnalité pour ajouter à chaque node un lien vers notre future liste de courses.
Attention cependant, contrairement à tous les hooks que nous avons étudié jusqu'à maintenant, celui là fonctionne de manière globale. C'est à dire qu'il n'est pas appelé spécifiquement pour un node de type produit. Et il est même utilisé ajouter des liens à d'autres éléments de Drupal, comme les commentaires. Il faut donc vérifier avant d'ajouter un lien qu'il s'agit bien d'un node, et que le type du node est bien produit. Ensuite tout passe par un nouveau tableau associatif pouvant contenir autant de liens que désiré. La syntaxe est assez simple pour être comprise en première lecture.
Maintenant que nous avons notre lien vers la liste des courses, il ne nous reste plus qu'à la mettre en oeuvre.
Avant de rentrer dans le vif du sujet, arrêtons nous un peu sur la manière dont Drupal gère les URL. Ces dernières sont de la forme http://mon_site_drupal?q=chemin1/chemin2 ou http://mon_site_drupal/chemin1/chemin2 selon que le mode "URL Simplifié" est actif ou non. La chaîne chemin1/chemin2, appelée path, est associée par Drupal à une fonction, appelée callback. Lorsqu'il est exécutée, ce callback est renvoyé à Drupal du code HTML qu'il va l'insérer dans le corps de la page. Cette association entre un path et une fonction callback est appelée un menu.
Chaque module a la possibilité de définir ses propres menus en implémentant hook_menu. C'est ce que nous allons utiliser pour afficher notre liste de courses :
Une fois le code ajouté allez à l'URL http://mon_site_drupal/?q=courses/liste_items et voyez le résultat. Notre texte s'affiche tranquillement au milieu de la page et le titre de la fenêtre du navigateur est bien Liste des courses.
courses_menu renvoie à Drupal un tableau dont chaque entrée est un tableau associatif définissant un menu. Ce menu associe comme nous l'avons vu plus haut un path à une fonction callback. Le choix de mettre le nom du module, courses comme premier élément du path est une convention permettant d'avoir des URL de la forme mon_module/mon_action.
A ce menu nous avons donné un titre (paramètre title) et vous aurez sans doute constaté qu'un lien avec ce texte est apparu en même temps que la liste dans votre bloc de navigation. Cette magie là, nous la devons au type de menu (paramètre type) positionné à MENU_NORMAL_ITEM. Cela indique à Drupal que ce doit être un menu visible.Enfin Le dernier paramètre access positionné à TRUE permet à n'importe quel utilisateur, anonyme ou pas, d'accéder à ce menu.
La fonction de callback commence par changer le titre de la page et poursuit par la construction du contenu HTML du corps qui sera renvoyé à Drupal.
Il ne nous reste maintenant plus qu'à mettre un véritable corps à notre callback pour obtenir enfin notre liste de courses
La fonction commence par deux lignes dont l'objectif est de demander à Drupal de prendre la feuille de style default.css qui se trouve dans le dossier du module, et de l'ajouter à la page finale. Pour plus d'informations sur cette méthode, reportez vous à ce tutoriel. Cette feuille de style va juste nous servir à mettre en évidence les lignes de produits qui doivent être rachetés.
La requête SQL qui suit nous permet d'itérer sur la liste des nodes de type produit en y ajoutant les informations de la table node_produit. Nous aurions pu seulement récupérer ici le nid et utiliser la fonction node_load mais cette méthode est beaucoup plus rapide. Ceci fait, le reste n'est plus qu'un travail de mise en forme du contenu de l'objet $node en ligne d'un tableau, qui sert de retour à la fonction de call-back.
La dernière colonne du tableau contient des liens qui représentent les actions par produit : modifier et diminuer. La première est simplement un raccourcis sur l'édition du node, la seconde va nous permettre de diminuer la quantité restant de produit d'un simple clique.
Notez l'utilisation de la fonction Drupal, l(…). Son rôle est de fabriquer un lien HTML à partir d'un texte et d'un chemin. Il est fortement conseillé de toujours utiliser cette fonction pour générer un lien et ainsi laisser Drupal en trouver la meilleur représentation URL.
Voyons maintenant comment câbler notre action diminuer.
L'action diminuer attend que Drupal sache reconnaître un path de la forme couses/diminuer/1234. 1234 représentant le nid de la ligne courante. Pour cela nous allons devoir créer un nouveau menu d'un genre un peu différent du précédent, c'est à dire capable de comprendre un paramètre (le nid) et ne devant pas s'afficher dans le bloc de navigation.
Plusieurs points méritent attention. Tout d'abord, la fonction arg(n). C'est une fonction Drupal qui renvoie le morceau du path courant se trouvant à la position n (n débutant à 0). Pour le path courses/retirer/1234, 1234 correspond donc à arg(2).
Pour ne pas surcharger la liste des menus de Drupal, nous n'ajoutons ce nouveau menu que lorsque le troisième argument, arg(2), est une valeur numérique. N'oubliez pas que le code de Drupal est exécuté à chaque requête utilisateur. Du coup, tous les hook_menu de tous les modules actifs sont balayés. Il est donc important d'optimiser au maximum.
Ensuite nous fabriquons un path dynamique à l'aide de cet argument et nous précisons à Drupal de passer cet argument en paramètre de la fonction de callback courses_callback_diminuer_quantite. Enfin, nous utilisons le type MENU_CALLBACK qui va nous permettre de créer un menu qui ne soit pas affiché dans le block de navigation.
Il ne nous reste plus qu'à écrire cette fonction de callback :
Comme tout menu, la fonction callback doit renvoyer un résultat à afficher, nous poursuivons donc le traitement en appelant la callback qui affiche le menu.
Le traitement effectué par cette fonction de callback consiste à charger dans l'objet $node le node dont le nid est passé en paramètre. Ensuite à décrémenter sa quantité puis à sauver le objet $node. Notez que cela aurais pu être fait en une seule requête SQL, sans passer par Drupal mais cela aurais été moins instructif.
Voilà, nous avons terminé notre premier module qui avec moins de 200 lignes de code, permet de faire tout ce que nous voulions. Il est évidemment possible d'aller beaucoup plus loin, d'ajouter des champs dans la liste pour simplifier l'édition par exemple ou encore utiliser des callback en ajax pour réduire le nombre d'items.
Quoi qu'il en soit, j'espère vous avoir montré à quel point, une fois les notions de base assimilées (hooks, nouveau type de contenu, menus, etc.) il est simple de forger un module qui corresponde parfaitement à un besoin particulier.
]]>Tout content, je commence simplement par mettre à jour (urpmi --auto-update) et je lance VirtualBox. Et là... patatra... Déjà, l'outil me prévient qu'il compte convertir ma VM pour la nouvelle version, candide, j'accepte. Ensuite, il s'arrête brutalement me déclarant que mes drivers ne sont pas à la bonne version.
Je vérifie par un petit coup de modinfo vboxdrv et en effet, c'est encore une 1.5.6. Je fais un rpm -qa | grep box, et là, j'ai un joli mix de 1.5.6 et de 1.6. Je décide de désinstaller l'ensemble par un sauvage urpme $(rpm -qa | grep box) (faite gaffe, il se trouve que je n'ai pas d'autre paquets qui contiennent le mot box). Et je relance une installation (urpmi virtualbox). Et là je m'aperçoit que c'est le paquet dkms-virtualbox qui coince, il m'insulte en disant que mon /lib/modules/blabla/build ne contient pas le bon kernel, ou quelque chose d'approchant.
Du coup, je me fâche, et je vire le paquet de source, dkms, dkms-virtualbox et virtualbox. Je vérifie qu'il ne reste rien dans /usr/src et je lance urpmi kernel-source-latest dkms dkms-virtualbox. Et miracle, ça passe cette fois. Sûrement un problème de ménage dans l'arborescence dkms. Bref, je vérifie par un modinfo vboxdrv que cette fois j'ai bien la bonne version du pilote et satisfait, je lance un urpmi virtualbox pour relancer enfin ma vm.
Et là, recoinçage, cette fois VirtualBox me dit que je n'ai aucun droit pour utiliser le driver (qui cette fois est le bon).
Là, je me dis que c'est dkms qui a monté le module en mémoire. Peut être que si je redémarre le service, le script /etc/init.d/virtualbox va magouiller deux trois choses en plus qui permette à un utilisateur standard de touche au module. Je lance donc un service virtualbox restart. Content de mes deux [OK], je relance une dernière fois ma VM, et là, miracle.. ça marche...
Je vais donc pouvoir utiliser cette nouvelle version de VirtualBox en me demandant comment un nouvel entrant, ex-windowsien, peut vivre ce genre d'aventure...
]]>