On Tue, Oct 12, 2004 at 07:04:19PM +0200, Achim Bohnet wrote:
> > 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)
>
> So a special case just for kdmrc?
Uh, well, yes. This whole bug is just about alleviating the pain of tracking
upstream (and Debian) changes to kdmrc.
Of course, it may be possible to extend my proposed approach to other
configs.
> There is also the problem that kde config tried to minimize
> changes: if a user and system config file contain the same setting
> it's removed from the user file.
User file? For kdm? Doesn't that only have things like previous session and
language and stuff? How does that enter the picture here?
> I've not thought about it how
> this could influence the four config file case. KDE config stuff
> is already complex enough for me >;-/
You can say that again...
> > The problem is _when_ to do this. The kdm initscript seems like a reasonable
> > place.
> AFAIK kdm reload config if modified before starting each chooser/login
> window.
I don't see how that is a problem. kdmrc would always contain the most up to
date config.
> > What do you think?
>
> I still have the feeling that it's too much effort.
I agree it's a lot more complex than I originally thought. However, thinking
of the frustration of merging kdmrc changes, I'm still not sure of the 'too
much' bit. :)
> My first try would be UCF but I done no experiments with it yet (UCF usage
> is still on TODO for my pkgs). So it may not help much in your case.
Well, if ucf can do a reasonable job of this, I'm sure we'll all be happy.
When do you think you'll be able to find out? Maybe someone with a better
understanding of ucf than either of us can provide advice?
Andras
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
Quantum Mechanics: The dreams stuff is made of.
