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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)