Je dois vous raconter mes petites mésaventures matinales pour vous faire mieux comprendre le pourquoi du comment de ce billet. Mais commençons par un peu de contexte.
Hier soir, le 22 novembre, je suis allé sur le forum d’EndeavourOS et je suis tombé sur un fil concernant une modification concernant le logiciel CUPS qui est l’outil de gestion des imprimantes dans le monde linuxien.
En effet, Apple qui a maintenu durant des années le code de CUPS l’a laissé pourrir toute l’année 2020. Si on regarde au niveau des modifications de code en ce 23 novembre 2020, une seule entrée le 27 avril pour dire que CUPS 2.3.3 était sorti. Je ne sais pas pourquoi, mais ce code en train de se dessécher à l’air libre, ça me rappelle les conditions de naissance d’un certain LibreOffice.
Un fork – plus qu’utile pour une fois – a été lancé par l’organisation OpenPrinting. Sur le fil du forum d’EndeavourOS, j’ai appris qu’il fallait modifier le service pour lancer cups. En effet, on est passé du service org.cups.cupsd à cups.service. Ce qui est ennuyeux pour les installations automatisées.
Autant dire que la plupart des installateurs facilitant sont impactés jusqu’à la sortie d’une nouvelle version et si on utilise un d’entre eux actuellement, comme Anarchy, EndeavourOS, RebornOS ou encore Calam Arch Installer, c’est mal barré pour avoir le service CUPS fonctionnel au démarrage si le besoin s’en fait sentir.
J’en ai profité pour prévenir Chennux qui maintient un « fork » de mon guide d’installation pour Archlinux sur github. Ainsi qu’Anarchy pour qu’il corrige le code touché par la modification du service utilisé.
Imaginez donc la bonne surprise avec un installateur non à jour en ce qui concerne CUPS. Bienvenue dans les joies de l’administration d’une base Archlinux.
J’ai fini la parenthèse du contexte. Ce matin, je vais sur youtube et je tombe sur une vidéo promouvant Calam Arch Installer (qui ressemble étrangement à EndeavourOS sur le plan des principes utilisés). Je me suis dit que la vidéo en question tombait bien mal.
Une nouvelle fois, ce n’est pas l’installation d’une Archlinux qui est complexe, il suffit de savoir lire et d’avoir de bonnes bases en anglais. C’est la maintenance sur le long terme, et quand ce petit genre de pépin arrive, nombre de personnes qui ne se doutaient pas de la difficulté d’administrer une installation d’Archlinux bazarderont le tout.
Mais il est vrai que ce n’est que la quinzième fois que je parle de ce problème… Mais comme on dit : il n’y a pas pire sourd que la personne qui se bouche les oreilles. Sur ce, bonne journée 🙂
A propos d’installateurs, ArchBang Linux semble en proposer deux. Si l’on en croit Jesse Smith sur Distrowatch ils sont, comment dire, perfectibles ? A lire ici: https://distrowatch.com/weekly.php?issue=20201123#archbang
Arch n’a as d’installateur « officiel » mais du coup plein d’officieux. Les mêmes causes produisant les mêmes effets, Slackware n’inclut pas d’outil avec gestion automatique des dépendances (et ne publie pas de listes de dépendances). Cela a fait naître une foultitude d’outils tiers … Je m’en tiens à slapt-get: un outil ça va, même imparfait (aucun n’est parfait), plusieurs bonjour les dégâts.
J’ai vu en vitesse que Jesse Smith avait été un peu déçu par Archbang. Le seul installateur officiel d’Archlinux, c’est son wiki. Donc, il faut savoir lire.
Enfin, je trouve dommage que Patrick n’ait pas intégré un gestionnaire de dépendances dans la Slackware, mais comme tu le dis slapt-get essaye de combler ce manque.
swaret a été proposé en /extra dans Slackware 9.1. Il a vite été retiré pour les motifs exposées par Patrick dans ce message: https://www.linuxquestions.org/questions/slackware-14/the-slackware-philosophy-4175419751/#post4743316
‘ai utilisé Slackware durant quelques années, en fait de 2005 à 2011, cette distribution est vraiment solide, j’ai un petit faible pour elle et l’installation même si en Ncurses est simple d’accès, même pour un débutant comme moi, cependant, autant avant les années 2000 ne pas avoir un gestionnaire de dépendances était logique, car les paquets n’étaient pas si nombreux (de mêmes que les distributions), autant en 2020 c’est un manque flagrant de pragmatisme, voire même de snobisme étriqué.
Il n’est pas normale de se coltiner un gestionnaire de dépendances non officiel, en fait c’est même légèrement schizophrène, car cela va à l’encontre de la philosophie même de la distro, surtout que le développeur toujours fait savoir qu’il était contre l’idée d’un gestionnaire de dépendances sur la Slackware.
Slackware a un gestionnaire de dépendances très fiable. Il s’appelle Patrick Volkerding. Il fait aux utilisateurs une promesse implicite et la tient remarquablement bien: si tu installes tout, tu ne manqueras de rien. Si tu veux ne pas tout installer, ou si tu veux ajouter des paquets tiers, libre à toi: dans ce cas c’est à toi de gérer les dépendances, pas à lui.
Ce choix me parait très raisonnable : étant seul à la barre il vaut mieux (et en tant que mainteneur d’une distribution dérivée de Slackware, je préfère de loin) qu’il consacre son temps à maintenir et faire évoluer Slackware tout en garantissant sa solidité que de se disperser à gérer des logiciels n’en faisant pas partie ou des configurations autres que celle de base.
Patrick ne souhaite pas intégrer à Slackware un outil de gestion des dépendances, parce qu’ayant essayé il en est résulté un flux de demandes de support pour de « mauvaises » raisons (en gros: gestion de paquets non inclus dans Slackware par des utilisateurs ne maîtrisant pas l’outil).
Cependant les utilisateurs sont bien sûr libres d’utiliser les outils qu’il veulent. La difficulté n’est d’ailleurs pas dans l’outil ou son utilisation, mais dans l’identification des dépendances. Des outils comme depfinder que j’utilise peuvent fournir une base mais il faut toujours vérifier et souvent modifier ou compléter « à la main » leurs résultats, pour inclure les dépendances à l’égard de Python, Perl, Ruby ou autres (ldd ne traite que les exécutables compilés), du contexte (logiciels installés au moment de la compilation qui génèrent de dépendances « parasites » peut-être superflues) et des options de compilation.
Je suis à deux doigts de repasser sous DOS en attendant la nouvelle Slackware pour tout dire.
La nouvelle slackware existe déjà, elle s’appelle : slackware-current
slackware-current est juste là pour tester en cuisine la nouvelle version (Slackware 15.0) en train de cuire. Tant que Patrick n’aura pas annoncé sur le ChangeLog « c’est prêt ! » il sera trop tôt pour passer à table 🙂
Certes
Mais bon dans le principe, il va geler la current et dire que c’est la 15
Dans le fond, ca change pas des masses
si vous voulez absolument un installeur, pourquoi ne pas installer manjaro ?
c’est une base arch non ?
il marche très bien chez moi, je viens de passer en noyau 5.9 il y a quelques jours de ça.
Manjaro n’est pas une archlinux pure, mais sa version temporisée et incompatible au niveau de la plupart des paquets.
Pour compléter (si mon cerveau n’est pas trop begué) manjaro est a arch ce que ubuntu est a debian.
manjaro me semble un bon compromis on profite de la base arch (et de ses dépots AUR vraiment pratique est riche) sans le coté trop barbu de sa distribution mère, mais on est pas enfermé dans un écosystème manjaro, si on désire se le faire a la barbu cela me semble tout a fait possible.
arch me semble plus destiné a des utilisateurs qui ont un besoin particulier comme faire du dev etc. ou aime le gout du sur mesure.
exact jbs13,
c’est la distribution que j’utilise le mieux sur mon mini PC.
pour l’instant zero bug.
en même temps je fais pas grand chose sur ma manjaro, a part naviguer sur internet et faire du virtualbox.
Oui, comme je t’ai dit sur Mastodon, j’avais vu ça samedi : après la mise à jour du paquet, 4 ou 5 lignes d’avertissement (consignées dans pacman.log, donc même si j’avais loupé ça, j’aurais bien fini par le voir au premier couac) disant que le service associé à CUPS avait été renommé en amont, et qu’il fallait donc procéder à quelques manips si besoin. Par chance, ils filaient deux lignes de commandes pour voir quel était le nom du fichier du service, pour comparer. Ça m’a bien servi, car j’ai juste eu à désactiver et stopper le « vieux » service org.cups.cupsd, puis activer et lancer dans la foulée le « nouveau » service cups (au passage, c’était pas déjà cups.service, jusqu’en 2015 à peu près ?). Sur le 2e PC, c’est allé encore plus vite, car je savais exactement quoi faire et que j’avais déjà effectué la procédure.
Le vrai manque, c’est que, pour une fois, rien n’a été dit à ce sujet sur la page d’accueil et d’actus d’Arch Linux (quand il faut forcer l’écrasement d’un fichier avec pacman, là, ils savent prévenir ; mais ici : rien, nada, que dalle). Si on est du genre à fermer trop vite le Terminal ou se déconnecter aussi trop vite de sa session TTY, on se fait vite avoir (et je parle même pas de ceux passant par Pamac ou autre outil graphique qui va rien signaler non plus, vu que ce n’est pas quelque chose de bloquant pour le processus de mise à jour)…
Enfin, heureusement que ce genre de chose n’arrive pas tous les jours !
Salut Fred,
Je m’intéresse peu à Arch pour l’instant, mais le moment venu, je passerai certainement directement par elle plutôt que par ses dérivées. Ou à la limite Parabola qui a une philosophie libre.
L’installation me semble justement très pédagogique (bien qu’effrayante de prime abord si on compare à des ubuntu etc.).
Salut Tonton Fred,
merci pour l’info, je modifie de suite dans mon guide d’installation personnel.
Plein de bonnes choses.
Charles.
Je pensais que la team EndeavourOS ferait mieux que de proposer un ISO bugé sur leur site. Comme quoi rien ne vaut une installation à la main.
ISO toute aussi buguée chez les autres installateurs facilitant qui n’ont pas appliqué la correction pour cups et / ou qui n’ont pas encore proposé de nouvelle version intégrant le correctif.
… Et votre installation à la main sera toute aussi bugée, si vous ne faites pas le correctif vous même!
Petit supplément:
Monter une Archlinux en lignes de commande ne vaut la peine que si l’on comprend ce que l’on fait! Si c’est pour faire du copier/coller en suivant benoîtement un tuto…l’intérêt est plus que discutable!
Je suis le tuto en faisant du copier/coller avec les pieds j’ai bon ou pas ?
Hummmm…je ne sais pas trop! En tout cas, j’applaudi l’exercice ! 😀
moi qui n’ai pas d’imprimante ça me fait une belle jambe….de bois 🙂 sudo systemctl disable cups cups-browsed
Un petit retour manjaro n’a pas eu l’idée de faire la modif ou forcer un avertissement VISIBLE (vu la cible de cette distribution et comme elle a un décalage « tampon » avec arch) si c’est un utilisateur lambda il risque d’avoir une surprise. (si je n’avais pas lu ce billet je me serait fait avoir plus galère pour trouver).
Une tempête dans un verre d’eau. Quand on rencontre ce type de problème, on n’est pas le seul concerné. Une recherche rapide peut nous sortir du pétrin. Je ne crois pas qu’il existe un seul monobootlinuxien qui ne sache se débrouiller de ce genre de péripétie. Les autres démarrent Windows et impriment.
Un grand merci pour l’info sur cups.