Implicitly set conf_files

[Gottox]

What about marking any files in /etc automaticly as conf_files. are there any counter-examples where this would break anything?

[Duncaen]

Yes scripts in /etc/sv/ and /etc/runit should probably not be conf_files by default, especially if a user sets keepconf=yes in xbps.d, which will always create .new-$version files even if the previous configuration file was never changed.

[sgn]

• Files provided by grml-zsh-config
• /etc/bash/bashrc (not sure about this one)

Those files shouldn't be marked as conf

[Chocimier]

Good idea.

Skimmed through xlocate, nothing besides what Duncaen pointed seems to need to be excluded.

[Gottox]

basicly Debian for example does.

[Gottox]

I'll make a PR that addresses this issue and respects @Duncaen's comments.

[travankor]

Should /etc/sv/service/confcount as conf?

[ericonr]

AppArmor profiles aren't conf files either. They are in /etc/apparmor.d/, but the local files in /etc/apparmor.d/local/ are conf files.

@Duncaen what do you think about making /etc/runit/ctrlaltdel a conf_file? It is something that a user can change depending on the action they want to trigger when they use that keyboard shortcut.

Should /etc/sv/service/confcount as conf?

@travankor IMO yes, it's where we recommend users make changes that persist across package updates. I believe the vsv function marks those as conf by default.

How would this work for new applications that for some reason store files in /etc that aren't config files? Will we have a new no_conf_files or no_auto_conf_file field, or have to add exceptions to the script?

---

To keep track, stuff I can think of in /etc/ that aren't conf:

• kernel.d/
• os-release ?
• some/most(?) of the stuff in zfs/
• polkit-1/rules.d/50-default.rules

[ericonr]

Ping?

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[Chocimier]

Blocked on void-linux/xbps#342