Re: Rhythmbox

[Greg Troxel <gdt%lexort.com@localhost>]

Jeff <pacavegano%odonian.org@localhost> 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.