thomas.koppandClaude Opus 5
035c88c31c
The lists are derived rather than typed. beastix has 512 explicit packages - years of experiments among them - so taking that as "what this machine needs" would be meaningless. curate.sh combines four usage signals, each of which alone has a blind spot: shell history sees no GUI application, KDE's activity database sees no chat client, autostart sees only what starts by itself, and flatpak entries never appear in pacman -Qqe at all. That reduces 512 to 62. The split follows the data: what beastix and shron both have becomes the base, the rest of beastix becomes desktop, shron's own becomes server. base-devel is one entry in the server list rather than its 26 members. It stopped being a package group in 2022 - "pacman -Sg base-devel" now fails outright - and is a meta package today. base, grub and linux-lts are dropped entirely; they arrive with the operating system. packages.sh never removes anything. Extras are reported and left alone, for the same reason the BookStack playbook refuses to: on a server, individual packages carry mail and web services. It avoids process substitution because /bin/sh is dash on Debian and a POSIX-mode bash on macOS, and this has to run on both. Verified on beastix: 62 wanted, 0 missing, 450 extra reported and untouched; install is a no-op. The server list is a snapshot from 2026-08-06 and wants re-reading when shron is reachable again - its login session has since expired. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DISCLAIMER:
this is not my work I've the idea from https://developer.atlassian.com/blog/2016/02/best-way-to-store-dotfiles-git-bare-repo/
In his words the technique below requires:
No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.
but for reason: ;)
- git and
- curl
How it work
The technique consists in storing a Git repository in a "side" folder (like $HOME/.cfg or $HOME/.myconfig) using a specially crafted alias so that commands are run against that repository and not the usual .git local folder, which would interfere with any other Git repositories around. Starting from scratch
If you haven't been tracking your configurations in a Git repository before, you can start using this technique easily with these lines:
git init --bare $HOME/.cfg
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
config config --local status.showUntrackedFiles no
echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc
The first line creates a folder ~/.cfg which is a Git bare repository that will track our files. Then we create an alias config which we will use instead of the regular git when we want to interact with our configuration repository. We set a flag - local to the repository - to hide files we are not explicitly tracking yet. This is so that when you type config status and other commands later, files you are not interested in tracking will not show up as untracked. Also you can add the alias definition by hand to your .bashrc or .zshrc or use the the fourth line provided for convenience.
I packaged the above lines into a snippet up. So that you can set things up with:
curl -Lks https://ls.shron.de/dotconf | /bin/bash
After you've executed the setup, any file within the $HOME folder can be versioned with normal commands, replacing git with your newly created config alias, like:
config remote add dotconfs url.to.remote.repo
config checkout
config status
config add .vimrc
config commit -m "Add vimrc"
config add .bashrc
config commit -m "Add bashrc"
config push
Install your dotfiles onto a new system (or migrate to this setup)
config pull