[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Preserving config across updates



> There are a few things which seem to reset themselves to defaults when
> upgraded without offering an option to keep the old config:

> - Eterm resets all of its 'system' (i.e., the ones in

> - My default window manager _usually_ stays at WindowMaker but, in my last

> system themes instead of customizing them within my user home directories.
> 
> As for the window manager, though, I thought the entire purpose of the
> alternatives system was that you could set the priorities according to your
> preferences and then not have to worry about your defaults being changed by
> new package installations or upgrades.
> 
> Also, many other packages will check to see whether you've modified your
> config files and give you the option to keep the current version, replace it
> with the maintainer's new version, or resolve the differences manually.
> Neither of these cases offer this choice; they just blow away the existing
> file without bothering to look at it first.
> 
> How can I prevent apt/dpkg from blindly overwriting these (and, potentially,
> other) configurations in the future?  And should these cases be reported as
> official bugs against the involved packages?  (If so, what would be the
> appropriate package for the window manager setting?  wmaker?  dpkg?)

I had the same thing happen when upgrading from potato r0 to potato r1, my
XF86Config file (and possibly others?) was overwritten with a useless
version, I have since gotten X into a state where it is (barely) usable,
but it is still highly crippled (Netscape and most panel applets difficult
or impossible to use, strange artifacts on screen). Prior to the upgrade
everything had been working smoothly since r0 came out. Potato r0 was the
most stable X I have ever used by a large margin, r1 is one of the worst. I
am using standard stable packages except for Helix gnome, but the problems
also occur running WindowMaker in a clean user account. And because the old
configuration file(s) was erased downgrading did not help (since
downgrading did not help I reupgraded).

I do not know what disturbs me the most, that this happened during a point
release in what is supposed to be debian-stable, or that the upgrade not
only did not ask permission to replace the configuration files, but also
deleted them instead of backing them up somewhere (and this with one of the
most critical and difficult to configure systems in the OS).

-- 
Harry Henry Gebel, ICQ# 76308382
West Dover Hundred, Delaware



Reply to: