Migration tool

[Alexander Sokolov]

Now I wrote the migration tool, this is bash script. For most files it just copies them to the new destination, but for autostart items from the session.conf my script creates desktop files.

II have a question. What the best way to automatically run it during user session start. 

• I can add it in the autostart list. But autostart processed after WM starting, so user gets WM select dialog. 
  
• Or I can add run it through QProcess on top of the RazorModuleManager::RazorModuleManager.
  

Ideas?

[PICCORO McKAY Lenz]

KDE runs migration tool (kde2->kde3 and also kde3->kde4) on top of process

debian has a migration tool (for kde3 legacy apps, to kde4 news) that run on top of proces, i recomend obviosly run on top of razorModule before loading windomanager.. this its usefully if user change any other settings, and can preserve for future cases of razor changes..

of course, the threath must be controled by first occurence..

--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en

--
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
Cofundador de Venenux;  debian based multimedia alike free only zealots users (oh well, i try but..too many free guidelines buahhh)
http://shutendouji.net
creador de massenkoh linux; debian enhanchements for better up to date support on stable brand, including non-free soft.

[Petr Vanek]

cool.

On May 30, 2012 (Wednesday), at 7:43 PM, Alexander Sokolov wrote:

Now I wrote the migration tool, this is bash script. For most files it just copies them to the new destination, but for autostart items from the session.conf my script creates desktop files.

I can only repeat what I said before. My original idea was

session will be started. It loads razor.conf and it will compare session version (compiled in), For this situation session knows it's 0.4.2, razor.conf does not contain any version tag so migration tool will be started to perform these files reorganization for end-user.

The migration-tool has to run

 - only when version comparation allows it (config file version is lesser than session's builtin)

 - before anything else will be started (from user's desktop)

 - synchronously. QProcess must wait until migration-tool will end.

Also the migration-tool should be able to allow more version-related changes.

Something like this (hypothetical scenario):

 - session version is 0.9.0

 - config version is 0.5.0

 - migration-tool contains steps which should go step-by-step:

   - 0.6.0 (change in panel.conf)

   - 0.6.1 (fix for change in panel.conf)

   - 0.7.0 (new desktop component, desktop.conf reorganization)

   - 0.8.0 (foobar blahblah...)

   - etc.

BTW I really appreciate your effort, it's hard work ;)

But (and it's only a note) bash is not available on all X11 platforms by default (solaris, bsd?) and also debian is dash-ized now. I'm not seasoned script coder but would it be much harder to use "sh" only? Without "bashisms"?

just my 2c

petr

II have a question. What the best way to automatically run it during user session start. 

• I can add it in the autostart list. But autostart processed after WM starting, so user gets WM select dialog. 
  
• Or I can add run it through QProcess on top of the RazorModuleManager::RazorModuleManager.
  

Ideas?

--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en

<razor-migration.sh>

[Kevin Krammer]

On Wednesday, 2012-05-30, Alexander Sokolov wrote:
> Now I wrote the migration tool, this is bash script. For most files it just
> copies them to the new destination, but for autostart items from the
> session.conf my script creates desktop files.
>
> II have a question. What the best way to automatically run it during user
> session start.
>

> - I can add it in the autostart list. But autostart processed after WM

> starting, so user gets WM select dialog.

> - Or I can add run it through QProcess on top of the
> RazorModuleManager::RazorModuleManager.
>
> Ideas?

You might want to look into the kconf_update tool (kdelibs/kconf_update).
It has been used by KDE for several years to update configuration of KDE
services and KDE applications (applications authors can use it to update their
config files by simply installing a trigger file).

It understands versioning, can do most INI file changes itself but can
alternatively also run a helper script.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

[Александр Соколов]

2012/5/31 Kevin Krammer <anda...@gmail.com>

You might want to look into the kconf_update tool (kdelibs/kconf_update).
It has been used by KDE for several years to update configuration of KDE
services and KDE applications (applications authors can use it to update their
config files by simply installing a trigger file).

It understands versioning, can do most INI file changes itself but can
alternatively also run a helper script.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

Very interesting tool, I think that porting will not be hard, IMHO we should use it. I'm putting the original readme text.

README kconf_update

Version: 1.1

Author: Waldo Bastian <bas...@kde.org>, <bas...@suse.com>

What it does

============

kconf_update is a tool designed to update config files. Over time applications sometimes need to rearrange the way configuration options are stored. Since such an update shouldn't influence the configuration options that the user

has selected, the application must take care that the options stored in the old way will still be honored.

What used to happen is that the application looks up both the old and the new configuration option and then decides which one to use. This method has  everal drawbacks:

* The application may need to read more configuration files than strictly needed, resulting in a slower startup.

* The application becomes bigger with code that will only be used once.

kconf_update addresses these problems by offering a framework to update configuration files without adding code to the application itself.

How it works

============

Applications can install so called "update files" under $KDEDIR/share/apps/kconf_update. An update file has ".upd" as extension and contains instructions for transferring/converting configuration information 

from one place to another.

Updating the configuration happens automatically, either when KDE gets started or when kded detects a new update file in the above mentioned location.

Update files are separated into sections. Each section has an Id. When a section describing a configuration change has been applied, the Id will be stored in the file "kconf_updaterc". This information is used to make sure that a configuration update is only performed once.

If you overwrite an existing update file with a new version that contains a new section, only the update instructions from this extra section will be performed.

File format of the update file

==============================

Empty lines or lines that start with '#' are considered comments. Commas (,) are used to seperate fields and may not occur as part of any field and all of the keywords are case-sensitive, i.e. you cannot say "key" instead of "Key" for example.

For the rest the file is parsed and executed sequentially from top to bottom.

Each line can contain one entry. The following entries are recognized:

Id=<id>

With <id> identifying the group of update entries that follows. Once a group of entries have been applied, their <id> is stored and this group of entries will not be applied again.

File=<oldfile>,<newfile>

File=<oldfile>

Specifies that configuration information is read from <oldfile> and written to <newfile>. If you only specify <oldfile>, the information is read from as well as written to <oldfile>. Note that if the file does not exist at the time kconf_update first checks, no related update will be performed (script won't be run at all, etc.).

Script=<script>[,<interpreter>]

All entries from <oldfile> are piped into <script>. The output of script is used as new entries for <newfile>. Existing entries can be deleted by adding lines with "# DELETE [group]key" in the output of the script. 

To delete a whole group use "# DELETEGROUP [group]".

<script> should be installed into $(kde_datadir)/kconf_update, or kconf_update will not be able to find it. It's also possible to install kconf_update applications in $(kde_bindir)/kconf_update_bin, which opens the door to kconf_update applications that are written in C++ and use Qt's powerful string API instead.

If Script was issued after a "Group" command the behavior is slightly different:

All entries from <oldfile>/<oldgroup> are piped into <script>. The output of script is used as new entries for <newfile>/<newgroup>, unless a different group is specified with "[group]". Existing entries can be deleted from

<oldgroup> by adding lines with "# DELETE key" in the output of the script.  

To delete <oldgroup> use "# DELETEGROUP".

<interpreter> can be something like "perl".

It is also possible to have a Script without specifying <oldfile> or <newfile>. In that case the script is run but it will not be fed any input and its output will simply be discarded.

ScriptArguments=<arguments>

If specified, the arguments will be passed to <script>.

IMPORTANT: It has to be specified before Script=.

Group=<oldgroup>,<newgroup>

Group=<oldgroup>

Specifies that configuration information is read from the group <oldgroup> and written to <newgroup>. If you only specify <oldgroup>, the information is read from as well as written to <oldgroup>. You can use <default> to specify keys that are not under any group.

A group may be written either as "group" or as "[group]". The latter syntax makes it possible to specify subgroups: "[group][subgroup]".

RemoveGroup=<oldgroup>

Specifies that <oldgroup> is removed entirely. This can be used to remove obsolete entries or to force a revert to default values.

Options=<option1>, <option2>, ....

With this entry you can specify options that apply to the next "Script", "Key" or "AllKeys" entry (only to the first!). Possible options are:

- "copy" Copy the configuration item instead of moving it. This means that 

         the configuration item will not be deleted from <oldfile>/<oldgroup>.

- "overwrite" Normally, a configuration item is not moved if an item with the

         new name already exists. When this option is specified the old 

         configuration item will overwrite any existing item.

Key=<oldkey>,<newkey>

Key=<oldkey>

Specifies that configuration information is read from the key <oldkey> and written to <newkey>. If you only specify <oldkey>, the information is read from as well as written to <oldkey>.

AllKeys

Specifies that all configuration information in the selected group should be moved (All keys).

AllGroups

Specifies that all configuration information from all keys in ALL groups should be moved.

RemoveKey=<oldkey>

Specifies that <oldkey> is removed from the selected group. This can be used to remove obsolete entries or to force a revert to default values.

Example update file

===================

# This is comment

Id=kde2.2

File=kioslaverc,kio_httprc

Group=Proxy Settings

Key=NoProxyFor

Key=UseProxy

Key=httpProxy,Proxy

Group=Cache Settings,Cache

Key=MaxCacheSize

Key=UseCache

Group=UserAgent

AllKeys

RemoveGroup=KDE

# End of file

The above update file extracts config information from the file "kioslaverc" and stores it into the file "kio_httprc". 

It reads the keys "NoProxyFor", "UseProxy" and "httpProxy" from the group "Proxy Settings" in the "kioslaverc" file. If any of these options are present they are written to the keys "NoProxyFor", "UseProxy" and "Proxy" (!) in the group "Proxy Settings" in the "kio_httprc" file.

It also reads the keys "MaxCacheSize" and "UseCache" from the group "Cache Settings" in the "kioslaverc" file and writes this information to the keys "MaxCacheSize" and "UseCache" in the group "Cache" (!) in the "kio_httprc" file.

Then it takes all keys in the "UserAgent" group of the file "kioslaverc" and moves then to the "UserAgent" group in the "kio_httprc" file.

Finally it removes the entire "KDE" group in the kioslaverc file.

Debugging and testing

=====================

If you are developing a kconf_update script and want to test or debug it you need to make sure kconf_update runs again after each of your changes. There are a number of ways to achieve this.

The easiest is to not install the kconf_update script in the first place, but manually call it through a pipe. If you want to test the update script for your application KHello's config file khellorc, you can test by using

    cat ~/.kde/share/config/khellorc | khello_conf_update.sh

(assuming khello_conf_update.sh is the kconf_update script and ~/.kde is your $KDEHOME). This is easier than making install every time, but has the obvious downside that you need to 'parse' your script's output yourself instead of

letting kconf_update do it and check the resulting output file.

After 'make install' the kconf_update script is run by kded, but it does so only once. This is of course the idea behind it, but while developing it can be a problem. You can increase the revision number for each subsequent run of 'make install' to force a new kconf_update run, but there's a better approach that doesn't skyrocket the version number for a mediocre debug session.

kded doesn't really ignore scripts that it has already run right away. Instead it checks the affected config file every time a .upd file is added or changed. The reason it still doesn't run again on your config file lies in the traces kconf_update leaves behind: it adds a special config group '[$Version]' with a key 'update_info'. This key lists all kconf_update scripts that have already been run on this config file. It also adds a group for the script to $KDEHOME/share/config/kconf_updaterc. Just remove your script entries from both your rcfile and kconf_updaterc, 'make install',

and kconf_update will happily run your script again, without you having to increase the version number.

If you want to know what kconf_update has been up to lately, have a look at $KDEHOME/share/apps/kconf_update/log/update.log

Common Problems

===============

* kconf_update refuses to update an entry

If you change the value of an entry without changing the key or file, make sure to tell kconf_update that it should overwrite the old entry by adding "Options=overwrite". 

Have fun,

Waldo

--
Best regards,
Alexander.

[Kevin Krammer]

In case anyone is looking for usage examples check KMail's kconf_update
directory: http://bit.ly/KKpWcA

KMail is one of KDE's oldest applications so it has made use of this update
facility a lot of times.

1) Move config values between files:

Id=3.3-aegypten-kpgprc-to-kmailrc
File=kpgprc,kmail2rc
Group=,Composer
Key=showEncryptionResult,crypto-show-encryption-result
Key=encryptToSelf,crypto-encrypt-to-self
Key=showKeysForApproval,crypto-show-keys-for-approval

This gets the values for showEncryptionResult, encryptToSelf and
showKeysForApproval from the top level group of kpgprc and stores them in
kmail2rc, in group Composer, using even new key names

2) Renames/fixes keys in the file

Id=4
File=kmail2rc,kmail2rc
Group=Reader,Reader
Key=QuoutedText1,QuotedText1
Key=QuoutedText2,QuotedText2
Key=QuoutedText3,QuotedText3

Fixes spelling mistakes in config keys

3) Uses shell script to manipulate the config

Id=3.2-update-loop-on-goto-unread-settings
File=kmail2rc
Group=Behaviour
Key=LoopOnGotoUnread
Script=kmail-3.2-update-loop-on-goto-unread-settings.sh,bash

4) Uses perl script to manipulate the config

Id=1
File=kmail2rc
Group=sending mail,Transport 1
Script=upgrade-transport.pl,perl

Each update stores its id in the config file so kconf_update knows which ones
not to run again.

Since I have been a KMail user for ages, the respective entry in my KMail
config looks like this

update_info=kmail.upd:1,kmail.upd:4,kmail.upd:5,kmail.upd:6,kmail.upd:7,kmail.upd:8,kmail.upd:9,kmail.upd:3.1-
update-identities,kmail.upd:3.1-use-identity-uoids,kmail.upd:3.1-new-mail-
notification,kmail.upd:3.2-update-loop-on-goto-unread-settings,kmail.upd:3.1.4-
dont-use-UOID-0-for-any-identity,kmail.upd:3.2-misc,kmail.upd:3.2-
moves,kmail.upd:3.3-use-ID-for-accounts,kmail.upd:3.3-move-identities-to-own-
file,kmail.upd:3.3-aegypten-kpgprc-to-kmailrc,kmail.upd:3.3-
misc,kmail.upd:3.3b1-
misc,kmail.upd:3.4,kmail.upd:3.4a,kmail.upd:3.4b,kmail.upd:3.4.1,kmail.upd:3.5-
filter-icons,kmail.upd:3.5.4,kmail.upd:3.5.7-imap-flag-
migration,kmail.upd:3.5.7-imap-flag-migration-2,mailtransports.upd:initial-
kmail-migration,kmail.upd:4.0-misc,kmail.upd:4.2

Cheers,
Kevin

On Friday, 2012-06-01, Александр Соколов wrote:
> 2012/5/31 Kevin Krammer <anda...@gmail.com>
>
> > You might want to look into the kconf_update tool (kdelibs/kconf_update).
> > It has been used by KDE for several years to update configuration of KDE
> > services and KDE applications (applications authors can use it to update
> > their
> > config files by simply installing a trigger file).
> >
> > It understands versioning, can do most INI file changes itself but can
> > alternatively also run a helper script.
> >
> > Cheers,
> > Kevin
> > --
> > Kevin Krammer, KDE developer, xdg-utils developer
> > KDE user support, developer mentoring
>
> Very interesting tool, I think that porting will not be hard, IMHO we
> should use it. I'm putting the original readme text.
>

> *README kconf_update*
> *
> *
> *Version: 1.1*
> *Author: Waldo Bastian <bas...@kde.org>, <bas...@suse.com>*
> *
> *
> *What it does*
> *============*
> *
> *
> *kconf_update is a tool designed to update config files. Over time
> applications **sometimes need to rearrange the way configuration options
> are stored. Since **such an update shouldn't influence the configuration
> options that the user*
> *has selected, the application must take care that the options stored in
> the **old way will still be honored.*
> *
> *
> *What used to happen is that the application looks up both the old and the
> * *new configuration option and then decides which one to use. This method
> has **everal drawbacks:*
> ** The application may need to read more configuration files than strictly
> * *needed, resulting in a slower startup.*
> ** The application becomes bigger with code that will only be used once.*
> *
> *
> *kconf_update addresses these problems by offering a framework to
> update **configuration
> files without adding code to the application itself.*
> *
> *
> *
> *
> *How it works*
> *============*
> *
> *
> *Applications can install so called "update files" under
> **$KDEDIR/share/apps/kconf_update.
> An update file has ".upd" as extension and **contains instructions for
> transferring/converting configuration information *
> *from one place to another.*
> *
> *
> *Updating the configuration happens automatically, either when KDE gets
> started **or when kded detects a new update file in the above mentioned
> location.*
> *
> *
> *Update files are separated into sections. Each section has an Id.
> When a **section
> describing a configuration change has been applied, the Id will be **stored
> in the file "kconf_updaterc". This information is used to make sure **that
> a configuration update is only performed once.*
> *
> *
> *If you overwrite an existing update file with a new version that contains
> a **new section, only the update instructions from this extra section will
> be **performed.*
> *
> *
> *File format of the update file*
> *==============================*
> *
> *
> *Empty lines or lines that start with '#' are considered comments. **Commas
> (,) are used to seperate fields and may not occur as part **of any field
> and all of the keywords are case-sensitive, i.e. you **cannot say "key"
> instead of "Key" for example.*
> *
> *
> *For the rest the file is parsed and executed sequentially from top to
> bottom.*
> *Each line can contain one entry. The following entries are recognized:*
> *
> *
> *
> *
> *Id=<id>*
> *
> *
> *With <id> identifying the group of update entries that follows. Once a
> group **of entries have been applied, their <id> is stored and this group
> of entries **will not be applied again.*
> *
> *
> *
> *
> *File=<oldfile>,<newfile>*
> *File=<oldfile>*
> *
> *
> *Specifies that configuration information is read from <oldfile> and
> written **to <newfile>. If you only specify <oldfile>, the information is
> read from **as well as written to <oldfile>. Note that if the file does not
> exist **at the time kconf_update first checks, no related update will be
> performed **(script won't be run at all, etc.).*
> *
> *
> *
> *
> *Script=<script>[,<interpreter>]*
> *
> *
> *All entries from <oldfile> are piped into <script>. The output of script
> **is used as new entries for <newfile>. Existing entries can be deleted by
> **adding lines with "# DELETE [group]key" in the output of the script. *
> *To delete a whole group use "# DELETEGROUP [group]".*
> *
> *
> *<script> should be installed into $(kde_datadir)/kconf_update, or
> **kconf_update
> will not be able to find it. It's also possible to install **kconf_update
> applications in $(kde_bindir)/kconf_update_bin, which opens the **door to
> kconf_update applications that are written in C++ and use Qt's **powerful
> string API instead.*
> *
> *
> *If Script was issued after a "Group" command the behavior is slightly **
> different:*
> *All entries from <oldfile>/<oldgroup> are piped into <script>. The output
> * *of script is used as new entries for <newfile>/<newgroup>, unless a
> different **group is specified with "[group]". Existing entries can be
> deleted from*
> *<oldgroup> by adding lines with "# DELETE key" in the output of the
> script. *
> *To delete <oldgroup> use "# DELETEGROUP".*
> *
> *
> *<interpreter> can be something like "perl".*
> *
> *
> *It is also possible to have a Script without specifying <oldfile> or
> **<newfile>.
> In that case the script is run but it will not be fed any input **and its
> output will simply be discarded.*
> *
> *
> *ScriptArguments=<arguments>*
> *
> *
> *If specified, the arguments will be passed to <script>.*
> *IMPORTANT: It has to be specified before Script=.*
> *
> *
> *Group=<oldgroup>,<newgroup>*
> *Group=<oldgroup>*
> *
> *
> *Specifies that configuration information is read from the group <oldgroup>
> **and written to <newgroup>. If you only specify <oldgroup>, the
> information **is read from as well as written to <oldgroup>. You can use
> <default> to **specify keys that are not under any group.*
> *A group may be written either as "group" or as "[group]". The latter
> syntax **makes it possible to specify subgroups: "[group][subgroup]".*
> *
> *
> *RemoveGroup=<oldgroup>*
> *
> *
> *Specifies that <oldgroup> is removed entirely. This can be used **to
> remove obsolete entries or to force a revert to default values.*
> *
> *
> *Options=<option1>, <option2>, ....*
> *
> *
> *With this entry you can specify options that apply to the next
> "Script", **"Key"
> or "AllKeys" entry (only to the first!). Possible options are:*
> *
> *
> *- "copy" Copy the configuration item instead of moving it. This means that
> *
> * the configuration item will not be deleted from
> <oldfile>/<oldgroup>.*
> *
> *
> *- "overwrite" Normally, a configuration item is not moved if an item with
> the*
> * new name already exists. When this option is specified the old *
> * configuration item will overwrite any existing item.*
> *
> *
> *
> *
> *Key=<oldkey>,<newkey>*
> *Key=<oldkey>*
> *
> *
> *Specifies that configuration information is read from the key <oldkey>
> **and written to <newkey>. If you only specify <oldkey>, the information
> **is read from as well as written to <oldkey>.*
> *
> *
> *
> *
> *AllKeys*
> *
> *
> *Specifies that all configuration information in the selected group should
> * *be moved (All keys).*
> *
> *
> *AllGroups*
> *
> *
> *Specifies that all configuration information from all keys in ALL **groups
> should be moved.*
> *
> *
> *
> *
> *RemoveKey=<oldkey>*
> *
> *
> *Specifies that <oldkey> is removed from the selected group. This can be
> used **to remove obsolete entries or to force a revert to default values.*
> *
> *
> *
> *
> *Example update file*
> *===================*
> *
> *
> *# This is comment*
> *Id=kde2.2*
> *File=kioslaverc,kio_httprc*
> *Group=Proxy Settings*
> *Key=NoProxyFor*
> *Key=UseProxy*
> *Key=httpProxy,Proxy*
> *Group=Cache Settings,Cache*
> *Key=MaxCacheSize*
> *Key=UseCache*
> *Group=UserAgent*
> *AllKeys*
> *RemoveGroup=KDE*
> *# End of file*
> *
> *
> *
> *
> *The above update file extracts config information from the file
> "kioslaverc" **and stores it into the file "kio_httprc". *
> *
> *
> *It reads the keys "NoProxyFor", "UseProxy" and "httpProxy" from the group
> * *"Proxy Settings" in the "kioslaverc" file. If any of these options are
> present **they are written to the keys "NoProxyFor", "UseProxy" and
> "Proxy" (!) in **the group "Proxy Settings" in the "kio_httprc" file.*
> *
> *
> *It also reads the keys "MaxCacheSize" and "UseCache" from the group
> **"Cache Settings" in the "kioslaverc" file and writes this information to
> the **keys "MaxCacheSize" and "UseCache" in the group "Cache" (!) in the
> **"kio_httprc" file.*
> *
> *
> *Then it takes all keys in the "UserAgent" group of the file "kioslaverc"
> **and moves then to the "UserAgent" group in the "kio_httprc" file.*
> *
> *
> *Finally it removes the entire "KDE" group in the kioslaverc file.*
> *
> *
> *
> *
> *Debugging and testing*
> *=====================*
> *
> *
> *If you are developing a kconf_update script and want to test or debug it
> you **need to make sure kconf_update runs again after each of your changes.
> There **are a number of ways to achieve this.*
> *
> *
> *The easiest is to not install the kconf_update script in the first place,
> but **manually call it through a pipe. If you want to test the update
> script for **your application KHello's config file khellorc, you can test
> by using*
> *
> *
> * cat ~/.kde/share/config/khellorc | khello_conf_update.sh*
> *
> *
> *(assuming khello_conf_update.sh is the kconf_update script and ~/.kde is
> your **$KDEHOME). This is easier than making install every time, but has
> the obvious **downside that you need to 'parse' your script's output
> yourself instead of*
> *letting kconf_update do it and check the resulting output file.*
> *
> *
> *After 'make install' the kconf_update script is run by kded, but it does
> so **only once. This is of course the idea behind it, but while developing
> it can **be a problem. You can increase the revision number for each
> subsequent run **of 'make install' to force a new kconf_update run, but
> there's a better **approach that doesn't skyrocket the version number for a
> mediocre debug **session.*
> *
> *
> *kded doesn't really ignore scripts that it has already run right
> away. **Instead
> it checks the affected config file every time a .upd file is added **or

> changed. The reason it still doesn't run again on your config file lies

> **in the traces kconf_update leaves behind: it adds a special config group
> **'[$Version]'
> with a key 'update_info'. This key lists all kconf_update **scripts that
> have already been run on this config file. It also adds a group **for the
> script to $KDEHOME/share/config/kconf_updaterc. Just remove your **script
> entries from both your rcfile and kconf_updaterc, 'make install',*
> *and kconf_update will happily run your script again, without you having to
> **increase the version number.*
> *
> *
> *If you want to know what kconf_update has been up to lately, have a look
> **at $KDEHOME/share/apps/kconf_update/log/update.log*
> *
> *
> *
> *
> *Common Problems*
> *===============*
> *
> *
> ** kconf_update refuses to update an entry*
> *If you change the value of an entry without changing the key or file,
> **make sure to tell kconf_update that it should overwrite the old entry
> **by adding "Options=overwrite". *
> *
> *
> *
> *
> *Have fun,*
> *Waldo*