Re: Preserving config across updates
Dave Sherohman <esper@sherohman.org> 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 dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: