Audit Guix Home dotfiles for mutable state and generated artifacts #3

Open
opened 2026-08-17 04:34:28 +00:00 by htayj · 0 comments
htayj commented 2026-08-17 04:34:28 +00:00 (Migrated from github.com)

Goal

Audit the Stow-layout inputs imported by home-dotfiles-service-type and stop deploying mutable application state, caches, generated files, and backups as immutable Guix Home configuration.

Guix Home symlinks managed files to the store. Applications may fail to update mutable files, replace the symlink and drift from the Home generation, or create noisy rebuilds when state is accidentally committed.

Initial candidates

Review at least:

  • htop/htop_history;
  • welcome_news_latest_date_file;
  • display/output state such as kwinoutputconfig.json;
  • generated KDE/Plasma state files;
  • Ghostty *.bak-* files;
  • generated lock files or dependency directories under application config;
  • histories, caches, session state, machine identifiers, and updater markers generally.

Do not remove intentional declarative preferences merely because the application sometimes rewrites them. Never add credentials or other secrets to Guix Home or the repository.

Proposed implementation

  • Classify imported files as declarative configuration, generated artifact, mutable state, cache, or secret.
  • Remove state/cache/generated files from the managed source tree when safe.
  • Add narrow exclusion patterns for files applications recreate locally.
  • Ensure backup-file patterns cover the actual names present, not only editor ~ files.
  • Document any intentionally managed mutable-looking files.

Acceptance checks

  • Home build and reconfiguration succeed without duplicate destinations.
  • Applications can update their runtime state without attempting to write into /gnu/store.
  • No credentials, tokens, private keys, or machine-local identifiers enter the repository.
  • The audit leaves a documented list of intentionally managed configuration files and exclusions.

Imported from GitHub issue/PR. Originally posted by htayj on 2026-08-17T04:34:28Z.

## Goal Audit the Stow-layout inputs imported by `home-dotfiles-service-type` and stop deploying mutable application state, caches, generated files, and backups as immutable Guix Home configuration. Guix Home symlinks managed files to the store. Applications may fail to update mutable files, replace the symlink and drift from the Home generation, or create noisy rebuilds when state is accidentally committed. ## Initial candidates Review at least: - `htop/htop_history`; - `welcome_news_latest_date_file`; - display/output state such as `kwinoutputconfig.json`; - generated KDE/Plasma state files; - Ghostty `*.bak-*` files; - generated lock files or dependency directories under application config; - histories, caches, session state, machine identifiers, and updater markers generally. Do not remove intentional declarative preferences merely because the application sometimes rewrites them. Never add credentials or other secrets to Guix Home or the repository. ## Proposed implementation - Classify imported files as declarative configuration, generated artifact, mutable state, cache, or secret. - Remove state/cache/generated files from the managed source tree when safe. - Add narrow exclusion patterns for files applications recreate locally. - Ensure backup-file patterns cover the actual names present, not only editor `~` files. - Document any intentionally managed mutable-looking files. ## Acceptance checks - Home build and reconfiguration succeed without duplicate destinations. - Applications can update their runtime state without attempting to write into `/gnu/store`. - No credentials, tokens, private keys, or machine-local identifiers enter the repository. - The audit leaves a documented list of intentionally managed configuration files and exclusions. --- Imported from [GitHub issue/PR](https://github.com/htayj/dotfiles/issues/3). Originally posted by [htayj](https://github.com/htayj) on 2026-08-17T04:34:28Z.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
tay/dotfiles#3
No description provided.