il y a plus simple pour “raccourcir” la commande :

Mettre tout dans ~/stow/settings/ à la place de ~/settings/

stow settings

Je me pose une question par contre: est-ce que c’est possible de faire ça pour des programmes comme Firefox ? Qu’est ce qu’il se passerait si Firefox sur une machine modifie des fichiers synchronisés via Dropbox, ouverts en même temps sur une autre machine par Firefox ?

Mauvaise idée car y a des bases de données sqlite la dedans qui vont pas apprécier.

Mieux vaut utiliser firefox sync.

Du coup j’ai mis le dossier church/settings dans mon dossier Dropbox et j’ai toutes mes confs synchronisées. Vraiment très cool.

Je me pose une question par contre: est-ce que c’est possible de faire ça pour des programmes comme Firefox ? Qu’est ce qu’il se passerait si Firefox sur une machine modifie des fichiers synchronisés via Dropbox, ouverts en même temps sur une autre machine par Firefox ?

Ceci dit, moi j’ai une partition dédiée pour /home et je n’ai jamais eu de souci de portabilité. Tiens hier j’ai installé une Xubuntu64 bits. Ensuite j’ai récupéré mon home depuis mon autre xubuntu et ça a fonctionné nickel…

Parce que, de ce que j’en comprend : autant faire un git directement dans ton /home/user avec des règles d’exclusion dans ton .gitignore (déjà tous les dossiers/fichiers qui ne commence pas par “.”).

Ca évite de la gymnastique pour rien.

Stow reprend la config de ton /home/user pour les rassembler dans un autre dossier avec la même arborescence : pour moi, c’est un non-sens : elles sont justement pas éparpillés, elles sont déjà toute au même endroit.

Mais imaginons, tu veux la déployer sur une nouvelle machine flambant neuve : Tu clones ta conf dans ton dépôt dans /home/user je suppose.

Et du coup, tu peux pas rajouter, éditer de fichiers de ton nouveau poste… bref, git te sert plus que pour du pull.

Perso, j’ai gité mon .config avec le gitignore qui va bien.

Tous les trucs hors du .config, je les ai déplacé à la main + un script deploy.sh qui s’occupe de créer les liens.

Créer le script m’a mis quelques heures tout cumulé pour des années de loyaux services et c’est, à mon sens, plus rapide à déployer et étendre que ce que je vois de stow.

J’imagine que tu dois refaire la manip pour chaque nouvelle machine ? alors que je fais uniquement ceci : cd ~/.config && git clone masuperconfig.git && ./deploy.sh

Parce que avec stow, quand tu finis par adopter après coup un nouvel outil et son fichier de config, tu fais comment pour que toutes tes machines en profite rapidement?

Dans mon cas, ma backup mensuel m’indique que j’ai des nouveaux fichiers de conf (si il sont dans .config, ce qui est vrai dans 90% des cas), sinon, je les plug à la main.

Dans le cas de stow, il se passe quoi : t’es soit obligé de refaire la manip de synchro en entier, soit de linker les trucs en plus à la main… c’est donc au final, plus long, non ?

Enfin, ce qui me pèse le plus n’est pas la config en elle-même mais bien les dépendances correspondantes!

ex :

– cette config ne fonctionne bien que dans tmux >= version.

– ce bundle VIM, non présent dans les dépôts, a été installé via un wget mais je m’en souvenais plus…

Bref, j’ai presque résolu les choses en étendant mon script pour qu’il installe les dépendances tradionnelles via un sources.list + packages.list (ça reste ubuntu exclusive) et l’exotique à l’arrache (pip install, cargo install, npm prout, wget etc.)

@Brice: je suis comme toi j’ai la flemme de man

@François: c’est sam mais je ferai suivre :)

@fpp: oui je comprends pas qu’on en parle pas plus.

@Anne Onyme \o/