jeudi 24 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Derniers journaux de lucd :

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

Posté par dufresne luc (page perso, ) le 27 janvier 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 ?

> Lire le journal (15 commentaires, moyenne: 3,1).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Base de données relationnelle ?

Posté par nigaiden () le 27/01/2008 à 23:03. (lien). É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 Moonz () le 27/01/2008 à 23:10. (lien). É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 Vador Dark (Jabber id, ) le 28/01/2008 à 00:24. (lien). É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 Thomas () le 28/01/2008 à 11:16. (lien). É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 Aldoo (Jabber id, ) le 28/01/2008 à 11:35. (lien). É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 ?

    • [^]Re: Gruikerie

      Posté par CrEv (page perso, ) le 28/01/2008 à 12:15. (lien). Évalué à 2.

      J'ai vu passer dernièrement ce type de système pour versionner /etc, en liaison avec le gestionnaire de paquet (apt dans ce cas)
      - git : http://www.jukie.net/~bart/blog/20070312134706
      - mercurial : http://michael-prokop.at/blog/2007/03/14/maintain-etc-with-m(...)

      Maintenant, pour porter ça de manière simple pour un ~/.config c'est légèrement différent car il faut trouver le bon déclancheur pour le commit...

      • [^]Re: Gruikerie

        Posté par Aldoo (Jabber id, ) le 28/01/2008 à 12:55. (lien). Évalué à 2.

        À la rigueur, le déclencher manuellement pourrait suffire dans la plupart des cas.

      • [^]Re: Gruikerie

        Posté par gentildemon () le 28/01/2008 à 15:24. (lien). Évalué à 2.

        Maintenant, pour porter ça de manière simple pour un ~/.config c'est légèrement différent car il faut trouver le bon déclancheur pour le commit...


        Perso, je voterais pour le "close" sur le fichier pour le commiter.

bug report à la source

Posté par rewind () le 28/01/2008 à 13:32. (lien). É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)

  • [^]Re: bug report à la source

    Posté par tuXico () le 29/01/2008 à 15:07. (lien). Évalué à 2.

    +1

    (J'imagine que Tu veux faire faire le bug report à libetc)

    Du coup, à priori comme rewind, je suis content de voir Ton projet (surtout que je me tatais à coder la même chose) mais je souhaite sa mort à terme (personnellement, une des premières choses qui m'avait gêné sous mollusk, c'est la foultitude des fichiers ~/.*

    --
    Ce message aurait très bien pu être au second degré.

  • [^]Re: bug report à la source

    Posté par IsNotGood () le 30/01/2008 à 01:03. (lien). Évalué à 1.

    +1000

  • [^]Re: bug report à la source

    Posté par IsNotGood () le 30/01/2008 à 01:05. (lien). Évalué à 1.

    > (oui désolé, je veux la mort de ton projet :P)

    Pas moi. Je passe que libetc est intéressant. Mais pour les "bidouillages", cas particuliers, etc. Ça peut-être aussi une solution (limité) de cloisonnement.

Elektra

Posté par davux (Jabber id, page perso, ) le 30/01/2008 à 15:23. (lien). É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.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0752s (dont 0.0088 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.