salut Etienne, Bon déjà j'ai vu que "chez moi ça marche" c'est uniquement parce je me suis débarassé de systemd. ma réflexion est donc valable pour ces installs uniquements (ce qui veut dire "probablement très peu d'installs").
Après je dois avouer que lorsque j'ai viré systemd c'était idéalement au profit de sinit et je n'ai jamais fini. Je me retrouve avec openrc sans être satisfait non plus. L'idée est d'avoir une "suckless debian" fondé sur deux idées: * les outils les plus petits possibles pour pouvoir debugger/adapter facilement (dwm et sinit sont des outils du projet https://suckless.org/ mais j'utilise aussi des outils comme slim pour le display manager). par exemple je gère mon réseau comme suit et avec un autre helper pour wpa_supplicant: https://git.unistra.fr/mc/demo/-/blob/stable/suckless-debian/office * faire en sorte qu'une suite empirique de commandes apt-get install finisse in fine sous la forme d'un paquet pour: * faire le ménage facilement (apt purge lepaquet-en-question) * permettre à d'autres de ne pas tâtonner comme je l'ai fais (genre à la fin d'une tentative d'installation d'alphafold, j'ai un paquet unistra-alphafold-builddeps que je pourrais ensuite traduire en vrai build dep) pour le reste je suis très content de la qualité de debian (sauf pour l'évolution des tentatives de faire mieux que les apt-tools. aptitude un peu délaissé alors que cça roxe et apt qui devient un peu standard alors que je le trouve très mauvais) et suis heureux de ne pas avoir à me soucier du kernel ou de blender. On Thu, Jan 23, 2025 at 10:16:12PM +0100, Étienne Mollier wrote: > Je ne suis pas sûr d'avoir bien compris l'idée avec le lien > symbolique. S'il s'agit d'avoir un lien du script depuis le > cron.weekly vers le cron.monthly, du coup est ce que cron ne va > pas interpréter à la fois le lien dans le weekly et le fichier > d'origine dans le monthly? comme un bout de code vaut mieux qu'une longue explication, voilà coemment j'aurais tendance à gérer le truc (en tout cas la dernière version que j'avais en tête): https://git.unistra.fr/mc/demo/-/blob/stable/suckless-debian/system-cron-manager du coup: * les auteurs de paquets ne seraient pas impactés * on peut revenir facilement au comportement précédent évidement c'est un peu naif: il faudrait pouvoir gérer un lien symbolique vers un chemin absolu. > Ce que j'ai en tête, ce serait dans /etc/cron.weekly/$job > d'avoir tout au plus ce genre de commentaire : > # WARNING: frequency of the job has been reduced. > # Please refer to /etc/cron.monthly/$job for the real job. > # This file is left on purpose to prevent dpkg from duplicating > # the configuration in /etc/cron.weekly/ upon dwww upgrade. > > Le seul souci que je vois avec cette approche est que si le > fichier de configuration du paquet change avec des changements > intéressants (par exemple lors d'une mise à jour majeure du > système), alors les différences avec le fichier d'origine (qui > est désormais dans /etc/cron.monthly/$job) passent à la trappe > dans le diff proposé par dpkg lors de la résolution du conflit > sur le fichier de configuration. ce qui m'a probablement inspiré le script pointé ci-avant. en tout cas merci pour ton retour et bon WE. -- Marc Chantreux Pôle CESAR (Calcul et services avancés à la recherche) Université de Strasbourg 14 rue René Descartes, BP 80010, 67084 STRASBOURG CEDEX 03.68.85.60.79
