Oui je sais, je parle que de ça. Mais c’est comme ça, je suis un obsessionnel. Pkgin, vous l’avez peut-être vu sur GCU, a fait son entrée dans pkgsrc-wip. Depuis mon dernier post, beaucoup de fixes sont venus corriger des problèmes avérés ou potentiels, en majeure partie grace à mes testeurs chevronnés. Je pense que la version de ce soir, 20090517, marque une nouvelle étape dans l’évolution de mon apt wanabee, je commence enfin à m’attaquer à des aspects d’ordre “usability”, comme par exemple le fait de ne pas recharger la base si le mtime du pkg_summary(5) distant n’a pas changé, et m’assurer que l’outil est réellement utilisable sur des machines vierges.

Aujourd’hui, mon stress-o-meter a été mis à rude épreuve. Après plusieurs semaines de développement, j’ai fini par soumettre le résultat de mes travaux aux autres développeurs NetBSD. Et le résultat fut probant. J’ai fatalement reçu pas mal de feedback, d’idées et des pistes pour le futur de mon apt-like, mais tous étaient unanimes sur un point: pkg_dry, comme nom, ça craint.

Je n’étais moi-même pas bien satisfait de ce nom que j’avais trouvé un peu par dépit, constatant que l’idée initiale, pkg_get était déja prise.

Il parait qu’y’a un tool là, pour NetBSD, qui essaierait de mimer apt(8). Le gars il doute de rien, il a même pondu une page expliquant le projet. Je suis dubitatif.

Bon, blague à part, je pense que pkg_dry commence à être utilisable. Il reste encore quelques petites choses à ajouter, probablement un tas de vilains bugs et des ajustements divers, mais dans les grandes lignes, on y est.

Si donc vous vous sentez l’âme d’un testeur et que vous avez sous la main une machine / VM sous NetBSD ou DragonFlyBSD (voir ici pour ce dernier), je serais ravi de recevoir vos feedbacks.

Petit à petit, mon apt(8) wanabee prend forme. Hier j’ai passé deux étapes (ou pratiquement): actions sur plusieurs packages passés en paramètre et première approche de la fonction d’autoremove.

Pour la première, la finalité est évidente :

Pour la seconde, si la finalité semble tout aussi évidente, la mise en oeuvre l’est beaucoup moins. Pour le moment, l’autoremove est une action volontaire, exemple :

Je le sous-entend sans vraiment en causer depuis quelques semaines: je bosse sur un clone d’apt(8) pour NetBSD. Le projet n’est pas fini, loin s’en faut, mais j’ai atteint une Milestone aujourd’hui. Démonstration.

Installation :

Desinstallation :

Ça a l’air de rien comme ça, et c’est pas pour me lamenter, mais gérer les dépendances récursives et l’ordre de ces dernières pour pas que pkg_add(1) et surtout pkg_delete(1) ne gueulent, c’était pas une mince affaire. En tout cas, ça prend forme. En réalité, l’upgrade doit également fonctionner, mais, à nouveau pour satisfaire les ancestraux outils sus-cités, il faudra un peu d’astuce.

Pour tester “en vrai” mon fameux pkg_dry (work in progress, pas du tout utilisable, pas d’affolement), je devais posséder une VM NetBSD 5 “poubelle”. Seulement, depuis quelques temps déjà, je sais que cette version panic’e sur KVM, VirtualBox et Xen HVM. Aussi me suis-je décidé à Xenifier ma machine de developpement NetBSD qui n’a pas d’instructions VT, afin d’y faire tourner un domU en paravirtualisation.

Voici la compilation des documents utiles :

• Le HOWTO officiell NetBSD/xen (pas à jour)
• Le HOWTO du wiki NetBSD
• Un post sur port-xen qui donne quelques informations supplémentaires

Ce qu’il faut savoir :

Il y a 5 ans de cela, je vous entretenais sur la beauté des SLIST, un concept issu du monde BSD permettant de facilement manipuler des listes chainées dans votre code C sans avoir à réinventer la roue à chaque code.

Comme je n’avais plus manipulé ce type d’objet depuis un certain temps, je me suis replongé dans ce petit tutoriel, mais je lui ai trouvé un manque que je m’apprète à combler ici même.

Pour mon projet top secret que j’ai, j’avais besoin de télécharger un fichier, en C, via FTP ou HTTP. En cherchant ce qui est fait dans pkg_install, et plus particulièrement dans admin/audit.c, j’ai trouvé un bon exemple d’utilisation de la libfetch, dont le man est à mon avis complètement indigeste.

Petit résumé.

Afin de visualiser un code complet et fonctionnel sur l’utilisation de la libfetch, le fichier audit.c précedemment cité fera reference.

Considérons une fonction, fetch_url qui prendra en paramètre une URL. Afin d’utiliser la libfetch, nous auront besoin du header fetch.h. Voici donc le début de notre fichier contenant la fonction fetch_url :

J’ai dans mes cartons un “vieux” laptop Compaq. Ce dernier, bien que peu véloce, a une belle résolution, un clavier et une dale assez agréables, par conséquent, il faisait un candidat idéal au loutrage-canapé.

Mon premier reflexe fut evidemment d’insérer un CD de NetBSD 5.0RC2 fraîchement gravé, mais si l’installation et le boot furent une vraie rigolade, j’ai déchanté assez rapidement en voyant le noyau panic()’er aléatoirement :(

Qu’à cela ne tienne, je décide de me rabattre sur un NetBSD 4.0.1, valeur sure. Et vla que ça bloque au boot. J’aime pas les laptops Compaq. Comme je le suspectais, c’est evidemment cette grosse merde d’ACPI qui empêchait le noyau de se dérouler, donc à grands coups de userconf(4), je désactive acpi0. Démonstration :

Ce post est particulier. Sisi, il l’est. En fait je suis en train d’ecrire ce billet depuis vim. Rien de terrible me direz-vous, sauf qu’apres l’avoir sauvegardée, je pousserai cette news sur mon buergl avec… wpost.pl ! Cherchez pas, je viens de l’écrire et il est pas encore dispo (attendez encore quelques lignes). C’est pas compliqué, les trucs avec des boutons, des onglets, des checkboxes et tous ces trucs, j’y arrive pas. Alors puisqu’on est jamais mieux servi que par soi-même…