Bug#292401: kdm_config override /etc/kde3/kdm/kdmrc which is a conffile
severity 292401 serious
Justification: Break sarge_rc_policy.txt/3. Configuration files
> On January 26, 2005 17:56, Bill Allombert wrote:
> > Package: kdm
> > Version: 4:3.3.1-4
> > Severity: serious
> > Justification: Policy 10.7.3
> ...which states:
> Configuration file handling must conform to the following behavior:
> * local changes must be preserved during a package upgrade, and
> * configuration files must be preserved when the package is removed,
> and only deleted when the package is purged.
> Nothing kcontrol does violates policy 10.7.3, which describes package
> upgrades and removals. It does not forbid some GUI tool from completely
> re-writing the file, since running that tool is up to the user and has
> nothing to do with packaging policy.
If you prefer, read <http://release.debian.org/sarge_rc_policy.txt>:
(which is the official definition of RC)
3. Configuration files
Packages must not modify their own or other packages conffiles
programmatically. (The only correct way to modify a conffile is
the user running an editor specifically; if anything more automated
is required or useful, configuration files must _NOT_ be handled as
> That kcontrol does what it does is very annoying and a very nasty
> shortcoming, but not a policy violation.
You miss the point, it is not only a config file, but a *conffile*:
The easy way to achieve this behavior is to make the configuration
file a `conffile'. This is appropriate only if it is possible to
distribute a default version that will work for most installations,
although some system administrators may choose to modify it. This
implies that the default version will be part of the package
distribution, and must not be modified by the maintainer scripts
during installation (or at any other time).
> To fix this, we'd need either to ship a kdmrc that conforms to the
> kcontrol configurator's basic pattern, and so wouldn't be modified by
> kcontrol more than is really necessary (could we make it keep the
> comments, at least?), or else re-write the kdm module of kcontrol to
> behave less stupidly, which would be quite an undertaking.
Alternatively, you could stop shipping /etc/kde3/kde/kdmrc at all,
provide a non-config file /usr/share/kde/kdmrc, change kdm to read
/usr/share/kde/kdmrc if /etc/kde3/kde/kdmrc does not exist.
That mean people having a /etc/kde3/kde/kdmrc won't get the change
from /usr/share/kde/kdmrc, but currently they won't either if they
use kcontrol. I don't know if it is better.
Imagine a large red swirl here.