Dave Sherohman <[EMAIL PROTECTED]> writes: DS> There are a few things which seem to reset themselves to defaults when DS> upgraded without offering an option to keep the old config: DS> DS> - Eterm resets all of its 'system' (i.e., the ones in DS> /usr/share/Eterm/themes) themes back to the default settings on DS> every upgrade, requiring me to keep backed-up copies of my themes DS> and replace the default ones with them after each upgrade.
Yup, that's a feature. Anything under /usr (except for /usr/local/) is strictly dpkg's space; don't play with things there by hand, or they'll more likely than not be overwritten by the packaging system at some point. DS> - My default window manager _usually_ stays at WindowMaker but, in my last DS> dist-upgrade, the default became fvwm. Looking in DS> /var/lib/dpkg/alternatives, I discovered that wmaker's priority had been DS> reset from 5000 (which I had manually set it to in DS> /var/lib/dpkg/alternatives/x-window-manager, as the man page for DS> update-alternatives doesn't mention any way to change a package's priority DS> without removing and readding it) back to 50 and, since fvwm has the same DS> priority btu just happens to be listed first, it became the 'best' window DS> manager. Try reading the manual page again; in particular, see the description of update-alternatives' --config option, which takes a particular alternatives link out of auto mode. Note that for most things that require/allow user configuration, there are reasonable places to put things in one or more of /etc, /usr/local, or $HOME. For example, you can start the window manager of your choice from your .xsession file, or from GNOME's control panel if you're using that; for those purposes, it shouldn't matter what your system's "default" window manager is. If there's not a better way to install Eterm things, this seems like a perfectly valid thing to file a wishlist-priority bug about. DS> Also, many other packages will check to see whether you've DS> modified your config files and give you the option to keep the DS> current version, replace it with the maintainer's new version, or DS> resolve the differences manually. Neither of these cases offer DS> this choice; they just blow away the existing file without DS> bothering to look at it first. This only works for files that packages declare as configuration files. I'd be surprised if Eterm themes were declared so. Alternative priorities are "part of the packaging system" and can't be dealt with using this scheme. -- David Maze [EMAIL PROTECTED] http://www.mit.edu/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
