Journal Nouvelle version de libetc : vers la base de registre sous linux ;-)

Posté par  .
Étiquettes :
0
27
jan.
2008
Je viens enfin de faire un petit tar du dernier code de libetc qui traîne sur mon disque depuis quelques mois.

http://ordiluc.net/fs/libetc/

Pour rassurer tout le monde cela ne fait pas base de registre, mais cela centralise tous les fichiers de configuration d'un utilisateur : les applications sont forcées à stocker leurs fichiers de configuration dans $XDG_CONFIG_HOME (http://standards.freedesktop.org/basedir-spec/basedir-spec-0(...) ).

Pour les nouveautés : blacklist d'applications pour lesquelles on ne souhaite pas changer le comportement, facilité d'utilisation, bugfixes...

Et l'historique de toutes les versions dans des journaux précédents :
http://linuxfr.org/~lucd/23665.html
http://linuxfr.org/~lucd/22368.html
http://linuxfr.org/~lucd/17947.html

(record à battre: 27 commentaires)

ps: pour faire la base de registres, il suffit d'intercepter les appels read, write, seek... et d'envoyer tout cela dans MySQL ou PostgreSQL.

Et si quelqu'un souhaite coder, l'idée suivante est intéressante :
http://linuxfr.org/comments/799990.html#799990

La principale question est où stocker cette configuration ?

  • # Base de données relationnelle ?

    Posté par  . Évalué à 7.

    Serait-il intéressant d'envoyer ces fichiers de configuration dans une base de données relationnelle ? L'exercice serait certainement très instructif mais je doute de son utilité. Le système de fichiers fournit déjà une base de données hiérarchique et les outils classiques permettent de réaliser de nombreuses opérations (navigation, édition, suppression, duplication, sauvegarde, visualisation des différences, gestion de version...).

  • # Erratum...

    Posté par  . Évalué à 6.

    Bon, ça m'a l'air du bon, tout ça :)
    Je viens de me faire un ebuild, et trois remarques à chaud:
    - s/644/655
    - il manque install -d ${DESTDIR}${LIBDIR} (oui, si ${DESTDIR} n'est pas /, ${DESTDIR}/usr/lib n'existe pas forcément...)
    - les liens symboliques vers des bibliothèques, fais les relatifs, pas absolus (ln -fs libetc.so... au lieu de ln -fs ${LIBDIR}/libetc.so...)

    (pour répondre au commentaire de dessus: je pense que c'était de l'humour (noir, vu la référence à la base de registres) :))

    Merci pour cette formidable outil qui ne me quitte plus \o/

  • # Euh...

    Posté par  (site web personnel) . Évalué à 2.

    Le nom du journal, c'était pour tenter de battre ce fameux record de commentaire? :)

    Sinon, je ne pensais pas qu'on pouvait si facilement bypasser les fonctions de la libc... bien que je ne l'utiliserais pas personnellement, je garde ton code source sous le coude, ça peut toujours servir :).

    Euh sinon, pour utiliser une base de donnée MySQL pour stocker la conf(voir l'un des commentaires précédents), la meilleur solution(surtout si cela conserne le dossier /etc) ne serait-elle pas de passer par fuse?

  • # Gruikerie

    Posté par  . Évalué à 6.

    Intercepter les fonctions de la libc c'est furieusement gruikesque. Dans un premier temps pour tester sans modifier les applis ça va, mais à terme?

    Sinon je pense qu'il vaut mieux utiliser le système de fichiers, et de préférence dans le répertoire de l'utilisateur. C'est ce qu'on sauvegarde en premier (quand on sauvegarde) et ça permettrait de récupérer tous ses réglages persos avec une simple restauration du répertoire. On peut même pousser le vice jusqu'à faire du versionning des préférences utilisateurs via quelque chose comme Subversion ou mercurial.

    -- Thomas

    • [^] # Re: Gruikerie

      Posté par  . Évalué à 2.

      Eh, c'est franchement pas con, ça, de versionner les préférences !
      Est-ce que c'est utilisé en pratique, comme méthode ?

      Je sais que Windows fait plus ou moins ça avec la base de registres (sans doute à un niveau plus rudimentaire... ), pour laquelle plusieurs sauvegardes sont stockées et restaurables.

      Sur une plateforme Linux où l'on serait amené à tester plein de configs potentiellement gruik, ou bien tout simplement sur un serveur où l'on veut pouvoir revenir à une config stable au cas où une mise à jour ou une reconfiguration tournerait mal, ça pourrait être intéressant.
      Mais je crois que ce que dans ce dernier cas, on utilise plutôt les solutions classiques de sauvegarde, non ?

  • # bug report à la source

    Posté par  (Mastodon) . Évalué à 9.

    pourquoi ne pas faire de bug report sur au moins les gros projets ou faire des liens vers les bug report existant visant à l'utilisation de XDG_CONFIG_HOME ? ça permettrait de pousser à l'adoption de ce standard et à terme de ne plus utiliser libetc (oui désolé, je veux la mort de ton projet :P)

  • # Elektra

    Posté par  (site web personnel) . Évalué à 2.

    À noter aussi l'existence de Elektra, qui a aussi pour but de fournir une couche d'abstraction pour l'accès à la configuration, mais à un autre niveau :

    http://libelektra.org/

    Je n'ai pas regardé profondément ce que fait libetc, mais c'est peut-être possible de faire des choses en combinant les deux.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.