Je rappelle les principales différences entre ces paquets et une TeX Live nature (mis à part la facilité d’installation) : la version Debian/Ubuntu ne contient pas tlmgr, le gestionnaire de paquets TeX Live permettant une mise à jour en continu de paquets ; en revanche, biblatex, le nouveau gestionnaire de bibliographies avec BibTeX (encore en version beta) est inclus, et LuaTeX, le moteur TeX du futur, bénéficie de mises à jour en continu.

TeXworks

Par ailleurs, le nouvel éditeur intégré offrant une synchronisation native entre le source et le PDF, TeXworks, qui est distribué avec TeX Live sous Windows et avec MacTeX sous OS X, est également disponible en paquet Debian pour testing et en paquet Ubuntu pour Lucid.

Il est possible de les installer sur Debian testing. Pour cela, il suffit d’ajouter un dépôt « sid » à son /etc/apt/sources.list si ce n’est déjà fait, puis de lancer aptitude update et enfin aptitude -t unstable install texlive-full.

Les paquets ne sont visiblement pas encore arrivés dans Ubuntu lucid. Si je comprends bien la politique d’Ubuntu, ils devraient s’y trouver avant sa sortie (prévue en avril 2010). Je n’ai aucune information sur la possibilité qu’ils soient aussi backportés pour karmic.

Comparaison avec la TeX Live à la vanille

La première grosse différence entre une TeX Live nature et celle des paquets Debian, c’est que le gestionnaire de paquets TeX Live est tout simplement absent de cette dernière. En effet, Debian a son propre gestionnaire de paquets, et utiliser deux gestionnaires différents pour la même chose, c’est aller au devant de graves ennuis. Exit donc les mises à jour quotidiennes de paquets. (Ce qui n’est pas forcément grave, selon votre usage.)

L’autre grosse différence, qui va dans le sens contraire, c’est que le paquet Debian de LuaTeX est mis à jour en continu, contrairement au LuaTeX de TeX Live. Actuellement, c’est donc LuaTeX 0.46 qui est livré, et sans doute tout bientôt 0.47 (sorti hier). En même temps, LuaTeX est encore assez expérimental, donc cette information ne concerne que ceux qui sont assez aventureux pour les tester et avoir besoin des dernières fonctionnalités, mais qui n’ont pas envie de l’installer à la main sur leur TeX Live comme je l’expliquais précédemment.

(Ajout du 25 janvier.) Par ailleurs, biblatex n’est pas encore inclus dans TeX Live, par respect d’une demande explicite de l’auteur. Par contre, il a accepté que ce paquet soit inclus dans Debian, sans doute parce que le paquet n’est pour l’instant que dans la version testing, et qu’il espère sortir une version plus mature de biblatex avant que la prochaine Debian stable ne soit gelée.

À part ça, il est possible que quelques paquets ou documents aient été retirés des paquets Debian pour des raisons de licence. Globalement, les exigences de TeX Live et de Debian en matière de licences libres sont semblables, sauf sur deux points : TeX Live accepte les documents produits avec des polices non-libres, ainsi que ceux sous GFDL avec sections invariantes, que Debian n’accepte pas.

Petite parenthèse pour qui se demande d’où vient cette idée de désinstaller la libc : ça fait partie du folklore de fr.misc.bavardages.linux, un groupe iouzenette ma foi fort sympathique (voir ses conseils d’utilisation et notamment les liens de la section 4 (alerte procrastination) mais aussi le fortune-file (alerte bis)). La vérification du rapport avec la désinstallation de libc est laissée au lecteur.

Bref, souhaitant retrouver les termes exacts de la phase de sécurité en question (pour vérifier si elle suppose bien que l’utilisateur est de sexe masculin, ce qui ne serait pas forcément sexiste : une fille est bien trop responsable pour désinstaller sa libc…), me voilà parti à bidouiller les trois commandes sus-citées pour leur faire cracher le message. Quand, sûr de moi car n’ayant pas précisé --force-remove-essential je tape (en root sur mon laptop, qui est ma machine principale) :

dpkg --force-depends --remove libc6

à ma grande surprise ça « marche » (si l’on peut dire), sauf les scripts post-désinstallation, qui échouent, comme on devrait s’en douter. J’ai alors le plaisir d’entretenir avec mon shell préféré un dialogue aussi réjouissant que

% /bin/ls
zsh: command not found: /bin/ls
% ??!

le temps de réaliser ce que je viens de faire.

Arrivés à ce stade de votre lecture, vous êtes sans doute mort de rire. Même si j’en suis heureux, ce n’est pas la finalité principale de ce blog, qui avait plutôt pour but de partager des astuces techniques en LaTeX, ou en geekeries linuxiennes. La partie technique arrive : je vais vous expliquer comment il est facile de réinstaller sa libc. (Je lis la déception dans votre regard : rassurez-vous, ça m’a quand même pris un bon moment avant de comprendre que c’était facile.)

On s’arme bien sûr d’un bon Live CD, car le système n’est pas bootable (on pourrait en fait, avec l’option init=/sbin/sash mais je ne pense pas que ça avance à grand chose). Mon choix se porte que grml pour sa parenté avec Debian, son état d’esprit et sa finition que j’apprécie (je pratique aussi sysresccd à l’occasion). Je vous épargne les détails, mais je finis par découvrir ici l’option --root de dpkg qui semble résoudre mon problème.

Après avoir monté toutes les partition adéquates de mon disque dur (petit instant de doute en voyant qu’il n’y a rien dans /dev/mapper, mais la FAQ grml me conseille Start lvm et a bien raison), j’essaie et là c’est le drame : la version de dpkg du CD grml gravé il y a un an est trop vieille pour toucher à ma Lenny (la prochaine version de Debian) à jour. Yaka en graver une plus récente. Ou pas, parce que graver un CD en tournant sur Live CD, euh… Bref, vivent le boot sur clé USB, et les tutoriels qui marchent du premier coup (c’est aussi pour ça que j’aime grml).

Deuxième essai. Ok, dpkg fait de son mieux mais c’est le script d’installation qui marche pas : command not found: /bin/ls, ça vous dit quelque chose ? Visiblement --root en fait un peu trop. On passe donc au 6.3.7 de la page qui en parlait : faire soi-même le boulot de dpkg. Enfin, juste une partie de son boulot, lui il est plus subtil. Mais ça suffit, ouf.

Donc résumé en deux mots, le how-to (même si le mieux c’est de pas commencer, hein) :

1. Démarrer sur Live CD, récent ou pas.
2. Télécharger le .deb de la libc sur http://packages.debian.org.
3. Monter ses partoches ou volumes LVM du système cassé quelque part.
4. ar x lic6-*.deb où vous voulez, puis tar xf data.tar.gz à la racine du point de montage.
5. Redémarrage sur le système anciennement cassé, et dpkg -i libc6-*.deb quand même, juste pour que les petits papiers de dpkg soient à jour.

Morale de l’histoire : ne plus jamais tester des trucs idiots ailleurs que sur une machine de test (fut-ce une machine virtuelle ou un simple chroot).

Télécharger les sources du noyau sur kernel.org. Pour une version stable (ex. aujourd’hui : 2.6.27.7), utiliser le lien F (full source) sur la ligne. Dans tous les autres cas, il faut télécharger le patch (lien du numéro de version, ex. 2.6.28-rc6) et la base à laquelle l’appliquer, donnée par le lien B sur la même ligne. Dans les exemples qui suivent, je suppose que les trucs sont enregistrés sous ~/tmp.

Ajouter son utilisateur au groupe src si ce n’est pas déjà fait. Par exemple :

# adduser mpg src

Puis se relogguer avec cet utilisateur pour que la modification soit effective. Le vérifier en tapant id ou groups.

En utilisateur, aller dans /usr/src, y détruire le lien symbolique linux. Décompresser l’archive des sources. S’il s’agit d’une version à patcher, procéder comme dans l’exemple suivant.

% tar xjf ~/tmp/linux-2.6.27.tar.bz
% bunzip2 ~/tmp/patch-2.6.28-rc6.bz2
% cp -r linux-2.6.27 linux-2.6.28-rc6
% cd linux-2.6.28-rc6
% patch -p1 <~/tmp/patch-2.6.28-rc6

Une fois obtenue une belle arborescence des sources dûment patchée au besoin, rétablir le lien symbolique linux vers sa racine.

Il faut maintenant configurer le nouveau noyau. Pour partir de la configuration de l’ancien, faire par exemple

% cp /boot/config-2.6.27.5 /usr/src/linux/.config

Aller alors dans /usr/src/linux et y lancer alors make menuconfig. (Il faut sans doute installer un ou deux paquets pour ça, dont libncurses-devet peut-être d’autres.) Selon les besoins, sélectionner les drivers voulus (chez moi, c’est ath9k qui m’a motivé à installer une version récente du noyau, et que je vais activer la première fois dans Device driver -> Networks device support -> Wireless Lan -> Atheros 802.11n wireless cards support).

Il est alors temps de construire le noyau. Pour cela, il faut avoir installé les paquets nécessaires : kernel-package, fakeroot, build-essential et initramfs-tools en font partie, et je crois qu’ils suffisent. Exécuter alors

% fakeroot make-kpkg clean
% fakeroot make-kpkg --initrd kernel_image

(Si on envisage de faire plusieurs noyaux personnalisés successifs à partir d’une même version upstream, on a intérêt à utiliser l’option --append-to-version=.20081107 (ou tout autre numéro) pour les distinguer et ne pas mélanger leurs modules.) C’est en tout cas le moment de s’en jeter une petite de son breuvage favori, ou de faire autre chose d’intéressant sur sa machine si on elle a un double cœur.

Maintenant, la seule étape nécessitant les droits de root : l’installation du paquet créé.

# dpkg -i /usr/src/linux-image-2.6.27.5_2.6.27.5-10.00.Custom_amd64.deb

Voilà, il ne reste plus qu’à rebooter sur le nouveau noyau, et éventuellement recompiler les modules externes.

Premièrement, pourquoi avoir installé une TeX Live nature plutôt que les paquets TeX Live de Debian ? Plusieurs raisons :

• L’équipe TeX de Debian n’a pas encore eu le temps d’empaqueter la version 2008, et j’étais impatient de jouer avec les nouveautés de cette version.
• La version 2008 de TeX Live possède son propre gestionnaire de paquet, et je ne sais pas comment il sera utilisable dans la version Debian de la chose : dans le doute, installer la version nature me paraît raisonnable.
• Une raison personnelle : étant développeur TeX Live, il me paraît naturel d’utiliser la version nature pour mieux la connaître.

Maintenant, le problème qui se pose avec les installations locales, c’est que le gestionnaire de paquets de la distribution n’en est a priori pas au courant, et qu’il faudrait qu’il en tienne compte dans ses calculs de dépendance pour ne pas installer une deuxième version de ce qu’on a déjà installé. (On peut bien sûr choisir d’installer côte à côte une TeX Live de Debian et une nature, mais il faut être sûr de bien contrôler son environnement si on veut éviter les problèmes.)

La solution proposée par Debian tient en un mot : equivs. Ce petit paquet contient ce qu’il faut pour créer facilement des paquets Debian ne contenant rien à part des informations de dépendances pour APT. Voyons comment s’en servir pour créer un paquet texlive-local qui informera APT qu’on a déjà une TeX Live, merci. On commence par installer equivs et se mettre dans un répertoire temporaire de travail (je suppose que ~/tmp existe et que c’est là-dessous qu’on aime travailler). On commence alors par utiliser equivs-control.

# aptitude install equivs
$ mkdir ~/tmp/tl-loc
$ cd !$
$ equivs-control texlive-local

La dernière ligne a pour effet de préparer un squelette fichier de contrôle pour notre futur paquet. C’est là qu’on va indiquer à quels paquets Debian réels correspond notre installation locale, grâce à la ligne Provides:. On édite aussi quelques autres informations au passage (champs Package, Version, Maintainner et Description) ; le fichier obtenu est le suivant.

Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: texlive-local
Version: 2008-1
Maintainer: MPG <mpg@roth.elzevir.fr>
Provides: cm-super, cm-super-minimal, context, latex-beamer,
 latex-cjk-all, latex-cjk-chinese, latex-cjk-chinese-arphic-bkai00mp,
 latex-cjk-chinese-arphic-bsmi00lp, latex-cjk-chinese-arphic-gbsn00lp,
 latex-cjk-chinese-arphic-gkai00mp, latex-cjk-common, latex-cjk-japanese,
 latex-cjk-japanese-wadalab, latex-cjk-korean, latex-cjk-thai,
 latex-sanskrit, latex-xcolor, lmodern, luatex, musixtex, pgf, prosper,
 tex4ht, tex4ht-common, texinfo, texlive-base, texlive-base-bin,
 texlive-base-bin-doc, texlive-bibtex-extra, texlive-common,
 texlive-doc-base, texlive-doc-bg, texlive-doc-cs+sk, texlive-doc-de,
 texlive-doc-el, texlive-doc-en, texlive-doc-es, texlive-doc-fi,
 texlive-doc-fr, texlive-doc-it, texlive-doc-ja, texlive-doc-ko,
 texlive-doc-mn, texlive-doc-nl, texlive-doc-pl, texlive-doc-pt,
 texlive-doc-ru, texlive-doc-th, texlive-doc-tr, texlive-doc-uk,
 texlive-doc-vi, texlive-doc-zh, texlive-extra-utils, texlive-font-utils,
 texlive-fonts-extra, texlive-fonts-extra-doc, texlive-fonts-recommended,
 texlive-fonts-recommended-doc, texlive-formats-extra, texlive-full,
 texlive-games, texlive-generic-extra, texlive-generic-recommended,
 texlive-humanities, texlive-humanities-doc, texlive-lang-african,
 texlive-lang-arab, texlive-lang-armenian, texlive-lang-croatian,
 texlive-lang-cyrillic, texlive-lang-czechslovak, texlive-lang-danish,
 texlive-lang-dutch, texlive-lang-finnish, texlive-lang-french,
 texlive-lang-german, texlive-lang-greek, texlive-lang-hebrew,
 texlive-lang-hungarian, texlive-lang-indic, texlive-lang-italian,
 texlive-lang-latin, texlive-lang-manju, texlive-lang-mongolian,
 texlive-lang-norwegian, texlive-lang-other, texlive-lang-polish,
 texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-swedish,
 texlive-lang-tibetan, texlive-lang-ukenglish, texlive-lang-vietnamese,
 texlive-latex-base, texlive-latex-base-doc, texlive-latex-extra,
 texlive-latex-extra-doc, texlive-latex-recommended,
 texlive-latex-recommended-doc, texlive-latex3, texlive-math-extra,
 texlive-metapost, texlive-metapost-doc, texlive-music, texlive-omega,
 texlive-pictures, texlive-pictures-doc, texlive-plain-extra,
 texlive-pstricks, texlive-pstricks-doc, texlive-publishers,
 texlive-publishers-doc, texlive-science, texlive-science-doc,
 texlive-xetex, tipa, 
Architecture: all
Description: Installation locale de TeX Live.
 Installation locale d'une TeX Live nature complete.

C’est presque fini. Maintenant que notre fichier de contrôle est prêt, on peut créer le paquet et l’installer :

$ equivs-build texlive-local
# dpkg -i texlive-local_2008-1_all.deb

(Seule le dernière étape se fait en root ou avec sudo : dans tous mes exemples, $ ou % représent un shell utilisateur, et # un shell root.) On peut aussi si on le souhaite sauvegarder le paquet Debian créé : personnellement, je garde une copie de tous mes paquets créés localement dans /usr/local/debs.

Enfin, j’ai quand même installé lmodern, et tex-common dont il dépend, depuis les dépôts Debian : le but est simplement d’enregistrer ces polices au niveau de defoma et de X11. (Si j’étais un peu moins pataud en fontes, je le ferais à la main.) Le paquet tex-common ne risque pas d’interférer avec mon installation : il contient essentiellement des scripts de gestion propres à Debian.

Je peux ainsi installer (depuis les dépôts Debian) des éditeurs comme Kile ou TeXmaker, voire le module aucTeX pour Emacs (que j’essaierai un jour lointain, quand j’aurai beaucoup de temps) sans qu’Aptitude n’essaie de m’installer le moitié d’une TeX Live Debian en plus comme dépendances.

Tout d’abord, j’ai lancé un petit aptitude install wordpress et commencé à regarder ce qui se trouvait dans /u/s/d/wordpress. Il y avait un README et des exemples de configuration Apache et de script pour aider à créer une base mysql et permettre à wordpress d’y accéder.

J’ai d’abord été surpris de constater que le script échouait, tout simplement parce que je n’avais pas de serveur mysql qui tournait. Enquête faite, mysql-server est simplement suggéré par wordpress et pas installé d’office, car on pourrait en principe utiliser une bdd distante. Soit, j’installe mysql-server-5.0 et tout marche.

Mais après quelques minutes à configurer la chose, je change d’avis et me met à penser que c’est mieux d’installer wordpress à la main dans mon home : je trouve lourd d’avoir à être root pour installer des thèmes par exemple. Donc on efface tout et on recommence, sauf qu’avant de désinstaller on dit aptitude unmarkauto avec la liste des dépendances de wordpress histoire de les garder sous le coude.

Bref, je suis donc parti du site http://fr.wordpress.org/, j’ai téléchargé l’archive et l’ai dézippée dans ~/www/weblog. J’ai alors suivi les instructions en bas de page et plus spécifiquement celles présentes ici pour la création et configuration de la bdd. Tout a bien marché.

Par contre, en testant, j’ai une mauvaise surprise, provenant des exemples de .htaccess préalablement recopiés : il semblerait que la directive ErrorLog, qui ne provoquait pas d’erreur à la relecture de la configuration, faisait par contre tout bonnement mourir le serveur (dans des souffrances atroces, j’imagine) quand on tentait d’accéder à la page. J’ai abandonné l’idée d’utiliser cette fonctionnalité pour le moment.

L’autre petit souci est survenu quand j’ai voulu configurer des jolis permaliens : d’une part il faut penser à mettre le code aimablement fournit par wordpress dans une directive <Directory> comme nous l’apprend le message d’erreur. D’autre part, c’est stupide mais il faut y penser : il faut activer mod_rewrite

Pour finir, deux mots sur la configuration d’Apache. Comme souvent chez Debian, c’est un peu sophistiqué mais assez bien fait : pour les sites comme pour les modules, il y a un répertoire *-available et un *-enabled et on active les trucs en faisant des liens symboliques du deuxième vers le premier. J’en profite d’ailleurs pour place dans le home de mon utilisateur les fichiers de configuration propres à chacun des serveurs virtuels, et lui donne le droit grâce à sudo de demander à Apache de relire ses fichiers de configuration.

Je trouve ça plus pratique que de lister les sites virtuels dans le fichier de conf principal d’Apache puis d’utiliser des .haccess. D’une part, au moment du reload on a les messages d’erreur si les directives ne sont pas correctes, d’autre part, ça fait toujours un fichier de moins à analyser chaque requête pour Apache.

Bref, mon ~/www/weblog.conf Kimarch® est le suivant :

<VirtualHost *:*>
    ServerName weblog.elzevir.fr
    DocumentRoot /home/mpg/www/weblog
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]
    </IfModule>
    </Directory>
</VirtualHost>

Je crois n’avoir rien oublié, tout a l’air de marcher pour le moment.