fix: config path advisory ignores XDG file on interactive root (#81) #83
Reference in New Issue
Block a user
Delete Branch "fix/config-path-advisory"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
~/.config/numa/numa.toml, butconfig_dir()routed root to/var/lib/numa/andload_confignever consulted the XDG path — so the file the user created was silently ignored. The advisory and the code disagreed about where the config lives.suggested_config_path()helper insrc/lib.rsprefers$HOME/.config/numa/numa.tomlwhenHOMEis set (and isn't/or empty), withconfig_dir()as a lazy fallback. Wired into both advisories and intoload_configas an additional candidate, so the advised path is the one Numa actually reads.config_dir()anddata_dir()are deliberately unchanged. Runtime state (services.json, TLS CA) stays in FHS so an interactive-root session that later runsnuma installkeeps continuity with the installed daemon.load_configcandidate order is still(cwd, config_dir, data_dir, suggested). The XDG candidate is appended last, so any pre-existing FHS/Homebrew-prefix config (e.g. macOS/usr/local/var/numa/numa.toml) still wins as before. Verified in the docker regression scenarios.Test plan
cargo test --lib— 210 passed (6 new unit tests aroundresolve_suggested_config_pathcovering interactive user, interactive root, unset/empty//HOME, and lazy-fallback short-circuit)cargo clippy -- -D warnings— clean on touched filescargo fmt --check— cleancargo audit— clean./tests/integration.sh release— 68/68 passed./tests/docker/issue-81.sh— 4/4 scenarios match expectations:replication/main— user creates~/.config/numa/numa.toml, main ignores it (bug confirmed)replication/fix— user creates it, fix loads it and binds127.0.0.1:5354existing/main— pre-placed FHS config still loads (baseline)existing/fix— pre-placed FHS config still loads (no regression)Closes #81.