******************************************************************************
NOTE TO ALL USERS:

After 5 years I'm finally looking for someone capable of fully adopting cfg-update as I do not have the time to properly support it anymore. I will fix all remaining bugs in week 31 and write some documentation to enable someone else to continue developing it further...

I have submitted the new cfg-update-1.8.0-r1 ebuild for testing.
It will be added to portage (masked ~x86) very soon.
If you have questions, tips, suggestions or want to discuss bugs or
minor problems, you can use this thread.

I am happy to see a new version of cfg-update, the changelist seems very interesting and the addition of a bash version of the phphelper and the external config file both were commonly requested features (even if the *helper files may not be necessary anymore as you noted).
Congratulations !!

I have one small bug to report. I have just updated and when running cfg-update --help, I get the output twice (condensed to not take up too much room in the forum):

Code:

[13:02:00][root@xxxxx<xx.xxx.xxx.xx:/var/tmp]# cfg-update --help

USAGE cfg-update [flags] [runmode] (version 1.8.0)

FLAGS
[...]
For more info, type: man cfg-update

USAGE cfg-update [flags] [runmode] (version 1.8.0)

FLAGS
[...]
For more info, type: man cfg-update

[13:02:32][root@xxxxx<xx.xxx.xxx.xx:/var/tmp]#

Another small request: Would you be able to set the output of cfg-update which is seen during the emerge process to match the phphelper script, so that it is colored and looks like other emerge related output, something along the lines of replacing:

By colorise I actually just "bolded" "cfg-update:" so that regardless of the console background color it should look alright. You dont have to break it into two lines like that but I figured since I was reducing from 4 lines I could take up 2 and it would still be 50% savings.

Thanks again for the continued support and I look forward to testing this new version!

I have one small bug to report. I have just updated and when running cfg-update --help, I get the output twice

Thanks, this will be fixed in the -r2 version.

Quote:

Another small request: Would you be able to set the output of cfg-update which is seen during the emerge process to match the phphelper script, so that it is colored and looks like other emerge related output

Sounds good... I'll make it look like regular emerge output, just like your phphelper script.

Quote:

Thanks again for the continued support and I look forward to testing this new version!

Have fun with it, and thanks for your input!_________________When all else fails, read the manual...
Registered Linux User #340626

its nice how you listen to us - users - and how you improve this tool.

Today, I would like to know one thing - how cfg-update works with emerging in two or more consoles at the same time. I am using cfg almost for one year, but never did it. Mainly, becouse I wasnt sure, if its safe. Here is one example, to understand my question:

I start updating of 10 packages. At the begginig, cfg-update create checksum and emerge begin. After 4 updated packages (+some new config in /etc were created) I decide to emerge somethig small in another console. What will happen? How cfg-update handles this paralel emerges? Should some problems occuer?

I start updating of 10 packages. At the begginig, cfg-update create checksum and emerge begin. After 4 updated packages (+some new config in /etc were created) I decide to emerge somethig small in another console. What will happen? How cfg-update handles this paralel emerges? Should some problems occur?

Cfg-update will check the portage logs to see what the most recent emerged
package is. It then checks it's checksum-index, the first line contains the name
of the package that was emerged last when the checksum-index was updated.
If there is a difference it means that new packages have been installed after
the last indexing. So cfg-update will start looking in the protected directories for
._cfg0000_ files. If ._cfg0000_ files exist in the protected directories, indexing
is skipped... if they do not exist it will update the checksum-index with the MD5
hashes from the CONTENTS files.

So if portages stores the hashes before putting the file in the protected dirs,
there is a window of oppurtunity where things can go wrong. But the worst case
is that the second instance of cfg-update uses the MD5 hash of the new file
instead of the MD5 hash of the current file to determine if the current file has
been changed. If this happends, cfg-update will show the file as being modified
(while it's not) resulting in a forced manual merge in the GUI tool instead of an
automatic update.

The conclusion is that you don't have to worry about it... it's perfectly safe!_________________When all else fails, read the manual...
Registered Linux User #340626

Last edited by xentric on Thu Jan 05, 2006 7:19 pm; edited 1 time in total

shouldn't the alias be in bashrc not bash_profile?
I often do my updates using su, and this does not create a login shell so bash_profile doesn't execute ... right?

Thanks for pointing this out... I've googled around and found this.
Lot's of pages say that both .bashrc and .bash_profile can be used for user aliases,
but non-login shells like xterms do not read .bash_profile upon login. So .bashrc is
the best choice to put the alias in... You are absolutely right
I will change this in version 1.8.0-r3_________________When all else fails, read the manual...
Registered Linux User #340626

Not sure if it's something I did, but seems that in some cases the merged file loses permissions given on the original one. That caused some problems for me after updating init-scripts. The merged script didn't have it's executable-bit set.

Not sure if it's something I did, but seems that in some cases the merged file loses permissions given on the original one. That caused some problems for me after updating init-scripts. The merged script didn't have it's executable-bit set.

Hey this is weird. This was an issue with one of the old versions, but I
fixed it long ago. I will check it tonight!_________________When all else fails, read the manual...
Registered Linux User #340626

Did you disable backups in /etc/cfg-update.conf ?
If that's the case, I may have found the cause of your problem.
BTW, what version are you using?_________________When all else fails, read the manual...
Registered Linux User #340626

thanks for the response on my bashrc question.
unfortunately, this still wont allow cfg-update to do its thing when a command like sudo emerge ... is run, because a sudo command does not source any env setup files ... i dont think. Oh well, at least i can use su then normally.

also ... is there any way i can change the text cfg-update prints when updateing its index to be only one line and colored? can i modify the script or maybe change a wrapper to do this?

PS. i had the exact same issue when merging an initscript, /etc/init.d/clock. the executable bit was not set on the resulting (merged) file. as you can imagine this causes problems when booting/shutting down the system.

Did you disable backups in /etc/cfg-update.conf ?
If that's the case, I may have found the cause of your problem.
BTW, what version are you using?

Thanks for the reply. The config file I'm using is the default one, and backups are enabled. I was able to reproduce the phenomenon, however. Just altered the year from an init-script header, re-emerged baselayout and ran

Code:

sudo cfg-update -u -t /usr/bin/sdiff

chose the right column and accepted changes.
I wasn't using X at the time. The version I'm using is cfg-update-1.8.0-r1

Thanks for the reply. The config file I'm using is the default one, and backups are enabled. I was able to reproduce the phenomenon, however. Just altered the year from an init-script header, re-emerged baselayout and ran

Code:

sudo cfg-update -u -t /usr/bin/sdiff

chose the right column and accepted changes.
I wasn't using X at the time. The version I'm using is cfg-update-1.8.0-r1

I have fixed the bug. I still have to test some situations and fix some other things
but will try to get version 1.8.0-r2 out as soon as possible. Thanks for the info!_________________When all else fails, read the manual...
Registered Linux User #340626

This would probably be classified more as a wish than a bug and has been something I was manually changing since the first version I tried. I am only mentioning it now since the new use of a configuration file gives an acceptable solution to the problem.

On line 552 & 553 of /usr/bin/cfg-update you hardcode the Qt style of xxdiff. Could you either add in the config file a XXDIFF_OPTS where one could modify the style to suit their system or somehow detect the currently used style and apply it ? I have just in the past gone and hardcoded my existing style (baghira) but there could be an easier way (ie: autodetection)

Thanks again and I must say after a few days of usage I am really liking the 1.8.x branch !

Just submitted an update for cfg-update (1.8.0-r2)
I have fixed the following things:

1. It now correctly sets the executable bit after updating if the original file was executable.
2. It does not restore the MD5 checksum when restoring backups as that caused the file to be handled as unmodified even when it was modified because the wrong checksum was restored in the index... I found out that the original checksum can't be determined so I completely took this out. Restore files will be handled as modified files, forcing a manual update regardless of the true state of the file.
3. Added a variable to the cfg-update.conf that controls the GUI style of xxdiff.
4. Changed the indexing message to better match the style of emerge and added a setting to cfg-update.conf to controle the GUI style of xxdiff.
5. Removed the --fix option and moved the check for /root/.bashrc to the --on option. This has to be run manually after installation (because it changes a file in /root/)
6. Removed kdiff3 from RDEPEND in ebuild. Added text to the install instructions that a user can install different tools separately. xxdiff will remain the default tool.
7. Fixed reading of enable_backups setting from cfg-update.conf which was broken.
8. Fixed double printing of --help output
9. The .bash_profile and .Xdefaults file are no longer included in the tarball because putting the alias in .bashrc should be sufficient for using cfg-update.

Hi, I really love cfg-update and I really hope this will be the default for gentoo systems one day.

But that indexing upsets me.

I regularly emerge things and the indexing wastes a good amount of time on my 2GHz AMD 64. Is it really neccessary ? I would prefer one indexing when configuration files are actually being updated and not after each merge. Usually several packages are emerged before an update to the config-files happens. I don't see a reason why that indexing would have to happen after every single package that has been emerged - cause the merge of other packages doesn't touch the changes to the other packages config files - and even if it would they were cumulative.

I regularly emerge things and the indexing wastes a good amount of time on my 2GHz AMD 64. Is it really neccessary ?

There are several solutions:

I have included wrapperscripts to prevent indexing on non-installing usage of the emerge command and thus delays indexing until new programs...
Change the alias in /root/.bashrc to:
alias emerge='emerge_with_indexing_for_cfg-update_bashhelper'
OR
alias emerge='emerge_with_indexing_for_cfg-update_phphelper'

OR disable automatic indexing with "cfg-update -off" and update the index manually when you want with "cfg-update -i". The worst that can happen is that you'll have to update files manually while they could have been updated automatically if the checksum-index was up-to-date.

But can you also give me an idea of how long indexing takes on your machine?
I only have a Pentium3 850Mhz laptop with 256Mb RAM and a relatively slow 2,5" HD and about 400 installed packages. Indexing never takes longer than 10 seconds on my machine:

... OR disable automatic indexing with "cfg-update -off" and update the index manually when you want with "cfg-update -i". The worst that can happen is that you'll have to update files manually while they could have been updated automatically if the checksum-index was up-to-date.

Is there any difference in behaviour at all if I disable automatic indexing and do cfg-update -i + cfg-update -u after some merges ? If not wouldn't it be better to disable automatic indexing and instead make cfg-update check before any action like cfg-update -u if the index is up to date and if not then do the indexing before updating ?

xentric wrote:

But can you also give me an idea of how long indexing takes on your machine?
I only have a Pentium3 850Mhz laptop with 256Mb RAM and a relatively slow 2,5" HD and about 400 installed packages. Indexing never takes longer than 10 seconds on my machine

It only takes approximatly up to 5 seconds on my system - but it is still way too long if it happens every now and then.

Is there any difference in behaviour at all if I disable automatic indexing and do cfg-update -i + cfg-update -u after some merges ? If not wouldn't it be better to disable automatic indexing and instead make cfg-update check before any action like cfg-update -u if the index is up to date and if not then do the indexing before updating ?

I think you are right... except that cfg-update needs to update it's checksum-index as soon as possible after all config files have been updated and before new packages are being emerged.

I can simply put it at the end of the updating session... if cfg-update detects that all updates have been done it can simply update the checksum index. Which will only take 5-20 seconds at the end of an update session that completes all updates. This makes the alias for emerge obsolete and prevents delays during normal emerge usage.

A small voice in the back of my head keeps saying I used the emerge alias for a reason, but I can't figure out what would cause problems if we do this as I described above. So I'll start testing a new version of cfg-update which uses this method for updating the checksum-index.

Let's say you finish an updating session and the checksum index is updated. After this you emerge a new package foo-1.0 which uses a new config file /etc/foo. Then before you do any updating sessions a new version of foo is released and you decide to install foo-2.0. Now you get /etc/._cfg0000_foo but cfg-update doesn't know about /etc/foo because it has been installed after the last checksum-index update.
This makes cfg-update determine the file to be a custom file because it can't find an entry for /etc/foo in the checksum-index. This forces a manual update while it could have been an automatic update! But to put this in perspective, this situation would be rare if the user updates his config files before emerging new packages, as he/she should.

Advantages of the new, index updating without emerge alias, method:
++ no index checking/updating delays during emerge commands
++ no need for portage logging (PORT_LOGDIR) to determine if an index update is necessary or not
++ no need for an alias for emerge in /root/.bashrc
+ installation will require less fiddling...
Disadvantages new method:
-- there's no (easy/quick/fast) way to check if an index update is necessary or not
- you'll need a forced index update after cfg-update -u sessions (if all ._cfg0000_ files are gone)
- can't determine modification state of files that have been installed+updated after the last indexing

So the current method is more complete as it catches all possible autoupdates. But the advantages of the new method far outweigh the disadvantages. I'm going to implement this in the next version as the default way to update the index but I will keep support for the alias in there to prevent transition problems and to provide users with a choice.

When the "update_files" subroutine is finished it will call the "done" subroutine which checks if there are any ._cfg????_files left on the system.
If there are still updates on the system, it will prompt the user to run "cfg-update -u" again untill all updates are dealt with... and exits.
If it doesn't find any, it will check if there is an alias for emerge.
If the alias for emerge is enabled it skips the index update as the alias will take care of the index... and exits.
If no alias is found it will force an index update... then exits_________________When all else fails, read the manual...
Registered Linux User #340626

However, I haven't yet understood how I can get gvimdiff to show the .merge file separately, on a horizontal split (instead of a vertical split), just like in that xxdiff screenshot. Can some vim guru suggest some way of achieving that?

However, I haven't yet understood how I can get gvimdiff to show the .merge file separately, on a horizontal split (instead of a vertical split), just like in that xxdiff screenshot. Can some vim guru suggest some way of achieving that?

I'm glad that I've played around with vi in my early linux days... hahaha
All I needed was some vim command codes for navigating around in the files:

ctrl-ww = change cursor to the other window
do = obtain the diff from the other window
dp = put the diff in the other window
zo = unfold text without diffs
zc = fold text without diffs
]c = jump to next diff
[c = jump to previous diff
i = insert mode for text editing
:diffupdate = recalculate diffs
:qa! = close vimdiff without saving
:wqa = save changes and close vimdiff
ESC = if you don't know in what mode vimdiff is...

Just wondering what the undo/redo commands are

When the merge tool (vimdiff in this case) exits, cfg-update looks for the /etc/foo.merge file. If it doesn't find that file it checks if the current configuration file /etc/foo has been changed (MD5 checksum). If it has changed, cfg-update concludes that you have saved the merged result as /etc/foo and so it can complete the update by saving the backups /etc/._old-cfg_foo and /etc/._new-cfg_foo and removing /etc/._cfg0000_foo.

Because vimdiff stores an empty /etc/foo.merge file even when you have only looked at the files and haven't changed a thing, I need to force users to save the merged result as /etc/foo. So I have to make the right window "unmodifiable and read-only" to prevent accidental modification of the update file.

I have tested this method, and with the above information I was able to complete the update without problems...
(couldn't figure out how 3-way merging is done in vimdiff)

Just insert the following two lines in subroutine launch_tool (line 547) in /usr/bin/cfg-update:

I don't think vimdiff can, by itself, make a 3-way diff. However, I discovered a command yesterday:

Code:

comm -1 -2 file1 file2 > file1.merge

which strips out the lines from file1 and file2 which are not in common (and strips out some other common lines too ). That might be used to create a file1.merge and then pass on that file1.merge to vimdiff. But, I think it would probably be a ugly modification to your script.

However, many many thanks for providing a means of providing a 2-way diff through vimdiff!! Will test it out as soon as I get some time.

I didn't know about some of those commands that you have provided (diffupdate, for eg. zo, zc are general fold commands [to easily create a fold, press V, then use j/k or arrow keys to select text, and then type zf] ). To enable multiple undo's and redo's in vim, use :set nocompatible (nocompatible => not vi mode) and then 'u' and 'CTRL-r' are used for undo and redo respectively.