On Tue, Oct 12, 2004 at 03:54:50PM +0200, Achim Bohnet wrote:
> > I've seen ucf in action, and I don't see how it can be readily applied here,
> > or what its advantages over the proposed script would be. Do you have any
> > specific approach in mind?
>
> AFAIU your goal is to make merging of upstream changes in kdmrc easier.
>
> Currently kdmrc is a conffile and admin see all changes, regardless if the
> sys admin did them or it's an upstream change. Ucf AFIAU offers such
> merging. So visual clutter can be reduced.
In my experience, not by much; but maybe the other packages that use ucf
don't use it optimally.
> Your proposed solution with a splitted kdmrc and a update-* tool
> does not work easily because kdmrc can also manipulated by a kontrol
> center modules.
You're right. Too bad...
> So without modifying kdm & kcm_kdm you also have to
> ensure that changes via kcm module in kdmrc are 'backported' to the
> several little config files. IMHO not worth all the trouble.
Yes, it does look ugly at first sight; however, the backporting isn't so
difficult in itself:
1. generate kdmrc as it would look without kcm changes
2. diff with existing version; assume changes were made by kcm
3. propagate changes to kdmrc_kcm (a fourth config that takes precedence
over user, debian and upstream)
The problem is _when_ to do this. The kdm initscript seems like a reasonable
place.
What do you think?
Andras
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
Never accept a drink from a urologist.
