Jeff <[email protected]> writes: (I see you found the well-hidden state, so skipping that part.)
> Other package managers that I've used give the option (either > interactively or as a flag) to remove a program _and all associated > configuration_. I cannot find any such option for pkgin. Is there some > way to do this? (It's not really about pkgin, which is just a frontend for pkg_add and pkg_delete. But your question rephrased to that remains an excellent one.) Basically no. pkgsrc's scheme for "config files" is that config files live in PKG_SYSCONFDIR, nominally /usr/pkg/etc, sometimes in a package-named subdir (henceforth I'll just say /usr/pkg even though paths are in PREFIX and variable). These are config files for system programs. "example" config files are installed in /usr/pkg/share/examples/package, and there is code in the package Makefile in pkgsrc to say "at install time, copy this example to this path in /usr/pkg/etc **if it does not already exist**". The same mechanism will remove it on de-install **if it still matches**, so you don't lose your config, but configs for things you installed and removed without changing go away. There is no equivalent to the "purge configs" command in dpkg. I think that's ok, as basically you need to think about each, do you want to back it up, do you want to leave it, do you want to remove. It would be nice to have a "print the list of files in the config dir not claimed by an installed package" to help patrol them. For programs that have *user* config it's much harder. pkgsrc installs a program, and then the program stores config state someplace in the user's homedir (really, whereever the code says), and pkgsrc doesn't really get involved. Are you saying that other package managers somehow know about user config files written by a program and offer a purge command that removes all of those files? How does the sysadmin know that's what the users (all of them!) want? There are desktop standards about .config, .local, cache, and my interpretation of the situation you just went through is that it was harder than it needed to be because rhythmbox put state in an odd place. I looked at my system and things were messy between .local and .config, with config in both and non-config in both. The old-school place would have been .rhythmbox. I think it comes down to this just being a hard problem that requires paying attention. Long term, it would be nice if every upstream package only used .programname (best if not even) .config/programname (true configuration) .local/programname (state that isn't config) .cache/programname (bits that are downloaded/created and reused but if removed do not change semantics, just require work to get them again) and getting from here to there is a lot of work, much of it not about pkgsrc.
