******************************************************************************
NOTE TO ALL CFG-UPDATE 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 and write some documentation to enable someone else to continue developing it further...

WARNING: if you have used Paludis <0.20.0, you need to run cfg-update --check-packages
and follow the instructions! Due to a "bug" in the older versions of Paludis you risk losing
custom settings in the configuration files, belonging to packages that were installed with
Paludis <0.20.0, when using cfg-update.

About cfg-update (latest version: app-portage/cfg-update-1.8.2)

Many people have posted on the forums about their problems with the etc-update script which
is used for updating protected config files. As a result I decided to write an easy to use
script with a smart auto-update function, but without the risk of breaking your system.
I also added the possibility to use GUI diff/merge tools for updating all configuration
files that contain your customized settings. Combined with automatic backups this makes
a perfectly safe and convenient alternative for updating your configuration files.
It even has remote-updating functionality, so you can update multiple headless servers
from a single location with your favorite GUI or CLI merge tool!

See the Usage info section below for a walkthrough (based on xxdiff) with screenshots...

Note for first-time-users:the auto-update function may not work during the first update session!
cfg-update forces you to manually update your files with the GUI tool (easy clicking) until all
._cfg0000_ files are gone. After that cfg-update automatically updates the checksum-index
when you install new packages with Portage or Paludis and from then on it can use the MD5-
checksums to check if files have been modified and to determine if it's safe to auto-update files...

Features

- updating multiple machines from a single location (see /etc/cfg-update.hosts)
- updating with GUI or CLI tools of your choice (see /etc/cfg-update.conf)
- support for Portage and Paludis packagemanagers (via hooks)
- automatic updating of unmodified config files and unmodified binaries
- automatic 3-way merging of modified config files (only if backup of previous update is found)
- the above means that the script does more automatic updates the longer you use it
- it correctly handles file2link, link2file and link2link situations
- it creates backups before it touches your files so you can abort an update or restore files afterwards
- you can use the --automatic-only option for scheduling with cronjobs or other scripts
- supported GUI merge tools: xxdiff, kdiff3, meld, gtkdiff, tkdiff, gvimdiff
- supported CLI merge tools: vimdiff, sdiff, imediff2
- all features documented in the manpage (man cfg-update)

Installation

1. If you want the latest (unstable) version, you need to unmask first:
DON'T use ACCEPT_KEYWORDS="~x86" because that will emerge all the dependencies
with ~x86 too, which may have unexpected results. So, run this command before emerging:

If you prefer not to use "sux" but want to use regular "su" you can expect some
problems. First log out as root, and run "xhost +localhost" as the user who started
the X-server. Then use "su" to become root again to continue with the next step.
On commandline-only systems (without an X-server) you can't use "sux" and you'll
have to use "su" to run cfg-update (or try to get "sudo cfg-update" working).

4. You are now ready to start your first update session:

Code:

"cfg-update -l"
or
"cfg-update -u"

If you want to use another tool for merging, meld for example, you can permanently
change the GUI tool to meld in "/etc/cfg-update.conf" or temporarily on the commandline with
the -t option: "cfg-update -u -t /usr/bin/meld".

When you start cfg-update without any options it shows the help screen. Now run
"cfg-update -l" to see if there are any config files that need to be updated.
If it lists some files, just run "cfg-update -u" to start updating your files...

When xxdiff is started you see yellow regions with differences in both Panes.
If you click on the first yellow region in the RightPane it turns pink and the text is
inserted in the MergedPane. The text in the LeftPane turns blue and will be discarded.
Green regions are different, they only occur on one of the two sides. Just click on it
to insert it into the MergedPane.

You can also insert a single line from a yellow region into the MergedPane with
[shift h] for a line in the LeftPane, or [shift k] for a line in the RightPane.
Unselecting can be done with [ u ]. Look around in the menu for more hotkeys, you
can even choose [ s ] if you want to insert both versions of a region in the MergedPane.

NOTE: You can also edit lines with xxdiff, you need to choose "edit left/middle/right file"
from the File menu in the upper left corner of the window. This will start nano in the xterm
so you'll have to go back to the xterm where you started cfg-update...
Vimdiff also allows you to do this, but you'll need to know the "vi" commands to navigate
around in the files. (cfg-update prints simplified instructions before it spawns the diff/merge
tool, just emerge vimdiff and try "cfg-update -u -t vimdiff")
Because of this editing capability xxdiff is recommended for GUI and vimdiff for CLI.

When you're done merging the two files, just click on the save button with the M
or choose "save as merged" from the file menu to save the merge pane. Then exit xxdiff
and after that cfg-update will continue by looking for the .merge file you have just created.
The script will then save your changes (.merge file) to the current config file. If you have
enabled backups, which is the default setting, a copy of the ._cfg0000_ file is saved as
._new-cfg_* and the original config file is saved as ._old-cfg_* These can easily be restored
with the -r option so you can always re-try the update.
(The backups are stored in /var/lib/cfg-update/backups)

If you want to use another diff/merge tool, just set it in the configuration file
/etc/cfg-update.conf or use the -t option on the commandline. Any tool that can save
the merged result over the current configuration file, or a tool that can produce a
.merge file, should be OK.

If you experience problems, use the -v option to unhide STDERR messages!
Using "sux" instead of "su" to start a root session fixes most problems.

Error:"bash: cfg-update: command not found "
Try using "sux" instead of "su" first... else run:
cfg-update --fix
and read the man page if it tells you to edit some files...

Error:"Xlib: connection to ":0.0" refused by server"
Try using "sux" instead of "su" first... else type:
"xhost +localhost" (as the user who started the Xserver!)

Problem:The GUI diff/merge tool is not launched in X
If cfg-update is started in a virtual terminal it simply can't launch the GUI tool!
cfg-update checks the DISPLAY variable of the shell, if it is empty it means
that no X windows are available and cfg-update must use a CLI editor (like sdiff).
If the DISPLAY variable does contain a value, like when you run cfg-update in
an xterm or konsole, cfg-update will use the default GUI diff/merge tool for
updating your files. You can change the default tool in /etc/cfg-update.conf or
with the -t option on the commandline.

FAQ

How does cfg-update determine if a file has been modified?
I have implemented the same method as Naan Yaar's script.
Here's an explanation:
Portage stores MD5 checksums of all installed files in /var/db/pkg/*/*/CONTENTS
Cfg-update get's the MD5 checksum for the file you want to update and compares it to the
checksum that Portage holds in the CONTENTS file of the package that installed the file.
When they are the same, the file has not been modified by you or any program...
But there are a few problems:
When you emerge a new package and portage put's a new config file in one of the
protected directories, it's too late to match the checksum of the current config file with
the checksum from Portage because the CONTENTS file now contains the checksum of
the new file! So we make a backup of the checksums in /var/lib/cfg-update/checksum.index
We want to keep this backup as current as possible, so before we use emerge we should
check if we can update our checksum-index. We can update it only when there are no
._cfg0000_files in the protected directories otherwise we cannot determine if it has been
modified or not... and we don't want to type "cfg-update --index" before every emerge!
My simple solution:
With a hook in /etc/portage/bashrc we can run cfg-update --index everytime emerge is
used for installing a package... When cfg-update finds one or more ._cfg0000_files it will
not update the index until you have handled these updates. Because we cannot update
the index until all ._cfg0000_files are gone, the index will become older with every
emerge beyond this point. Ignoring this could possibly lead to files being shown as modified
while they are not which will result in not being able to use the automatic update function
on those files... This is fail-safe behaviour just to protect you from breaking your own system.

Can you explain the automatic and manual update methods?
Let's say we have a configuration file called /etc/foo and we get an update /etc/._cfg0000_foo for it...
A simple "cfg-update -u" will get you started. First the cfg-update script get's the MD5 checksum of /etc/foo and matches it with the checksum that Portage stored when it installed the file.

Situation A: If the checksum hasn't changed, you haven't made any changes to /etc/foo and it's safe to replace /etc/foo (containing only default settings) with the new version /etc/._cfg0000_foo.
Actions (automatic):
cfg-update moves /etc/foo to /var/lib/cfg-update/backups/etc/._old-cfg_foo to keep as backup
cfg-update copies /etc/._cfg0000_foo to /var/lib/cfg-update/backups/etc/._new-cfg_foo to keep as backup
cfg-update moves /etc/._cfg0000_foo to /etc/foo to update the configuration file
Actions (manual):
none, unless you disable automatic replacing of unmodified files with --manual-only (cfg-update -mu)

Situation B: If you have changed /etc/foo, the cfg-update script will see this when matching the checksums. The cfg-update script will open xxdiff (or meld,kdiff3,gtkdiff,kompare,sdiff,...) This tool shows you all the differences between /etc/foo and /etc/._cfg0000_foo and it let's you simply click on the lines you want to include in the merged result. The merged result is saved as /etc/foo.merged by the diff/merge tool when you are done.
Actions (automatic):
cfg-update starts xxdiff for you
xxdiff saves the merged result on exit as /etc/foo.merged
cfg-update moves /etc/foo to /var/lib/cfg-update/backups/etc/._old-cfg_foo to keep as backup
cfg-update moves /etc/._cfg0000_foo to /var/lib/cfg-update/backups/etc/._new-cfg_foo to keep as backup
cfg-update moves /etc/foo.merged to /etc/foo to update the configuration file
Actions (manual):
you only have to select which lines (settings) you want by simply clicking on them in xxdiff

Now pay attention, the backups are important because they can be used for 3-way merging!

Situation C: If you have changed /etc/foo, the cfg-update script will see this when matching the checksums. But it also sees that you have already updated this file before because it also finds /var/lib/cfg-update/backups/etc/._old-cfg_foo and /var/lib/cfg-update/backups/etc/._new-cfg_foo. In this case it will try to do an automatic 3-way merge...

3-way diff merging was created for this situation:
Monday morning, two programmers, John and Jim both want to add functionality to a program called foo-1.0. They both open the foo-1.0.c file in their editors and start changing the code... At the end of the afternoon they both have a different sourcecode file, each with their own changes in it. So John saves his result as john.c and Jim saves it as jim.c.
They use the following command to merge the results into a new file called foo-2.0.c:

Code:

diff3 -m john.c foo-1.0.c jim.c > foo-2.0.c

This will succeed as long as they didn't change the same lines!
So the format is: diff3 --merge versionA original versionB > merged-result

Now let's translate this to the configuration file update in Situation C.
You have edited the original /etc/foo file (versionA)
The devs have included an edited version of /etc/foo, which Portage just saved as /etc/._cfg0000_foo (versionB)
Luckily we also have a backup of the original file, the previous ._cfg0000_foo file!!! /var/lib/cfg-update/backups/etc/._new-cfg_foo (original)

So we can let diff3 do an automatic merge of your changes in /etc/foo and the changes by the devs in /etc/._cfg0000_foo and save the merged result as /etc/foo.merged
Actions (automatic):
cfg-update runs diff3 command
diff3 creates /etc/foo.merged which contains changes from both files
cfg-update moves /etc/foo to /var/lib/cfg-update/backups/etc/._old-cfg_foo to keep as backup
cfg-update moves /etc/._cfg0000_foo to /var/lib/cfg-update/backups/etc/._new-cfg_foo to keep as backup
cfg-update moves /etc/foo.merged to /etc/foo to update the configuration file
Actions (manual):
none, unless you disable the automatic 3-way merging with --manual-only (cfg-update -mu)

Situation D: Remember I said "This will succeed as long as they didn't change the same lines!" in the 3-way merge example? Well, in this case you have changed the file, and you have updated it before. But the automatic 3-way merge failed because of an merge-conflict... this happends when you and the devs both decided to change the same line differently. In this case cfg-update will open the three files in xxdiff 3-way mode. This means that you only have to solve the merge conflict manually by clicking on the lines you want in the merged result. You must choose between yours and the devs line(s).
Actions (manual):
cfg-update runs diff3 command
diff3 creates /etc/foo.merged which contains one or more merge-conflicts
cfg-update starts xxdiff for you
xxdiff creates /etc/foo.merged on exit which contains selected lines from both files
cfg-update moves /etc/foo to /var/lib/cfg-update/backups/etc/._old-cfg_foo to keep as backup
cfg-update moves /etc/._cfg0000_foo to /var/lib/cfg-update/backups/etc/._new-cfg_foo to keep as backup
cfg-update moves /etc/foo.merged to /etc/foo to update the configuration file
Actions (manual):
you only have to solve the merge-conflict in xxdiff by simply clicking on the lines you want to keep

Situation E..Z: Ofcourse there are lot's of other difficult issues too. The file that needs to be updated can be a symlink, a binary file or an executable file/binary, etc... It can even happen that you need to update files that haven't even been installed with Portage in the first place (custom files). All these issues are dealt with by cfg-update. If it can't decide what to do it will ask you!

So 90% of all updates are dealt with automatically by cfg-update, and the 10% that needs your help (uhmmm... simply clicking in a GUI tool) will shrink because cfg-update can use the backups for automatic 3-way merging on future updates!

So how does cfg-update handle all these situations?
All these situations are handled in a structured manner by cfg-update. After starting, cfg-update uses the portageq tool to determine which directories are protected. It then searches these protected directories for files starting with the ._cfg????_ prefix. Then it determines the situation (state) of each update. There are 9 different states:

Code:

state 1 [MF] [Modified File] - The configuration file has been modified
state 2 [MB] [Modified Binary] - The binary file has been modified
state 3 [UF] [Unmodified File] - The configuration file has not been modified since installation
state 4 [UB] [Unmodified Binary] - The binary file has not been modified since installation
state 5 [CF] [Custom File] - This file was not installed by Portage
state 6 [CB] [Custom Binary] - This binary was not installed by Portage
state 7 [LF] [Link to File] - The current symlink will be replaced by a new file
state 8 [FL] [File to Link] - The current file will be replaced by a new symlink
state 9 [LL] [Link to Link] - The current symlink will be replaced by a new symlink

These states need different approaches, so cfg-update handles them in 5 different stages:

Let's say you disable stage 1,2 with the --manual-only (-m) option, then cfg-update will place an update with state 3 (without backup of previous update) in the next stage that can handle this update... If a backup is available, the update will be placed in the queue of stage 3. If no backup is found it will be placed in the queue for stage 4.
You can also disable stage 3,4,5 with the --automatic-only (-a) option. This will ignore all updates that cannot be handled in stage 1,2. This option can be used in cronjobs or with other automated updating scripts.
Note: in the /etc/cfg-update.conf file you can permanently disable individual stages and change the preferred tool for merging.

Changelog

[11-july-2008]
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.
By the way, all those years I have wondered how many people are actually using cfg-update. I still have no clue!
I would really, really, really appreciate it if all you guys would send a shout to xentric@zeelandnet.nl with your name or nickname and your location, just for the fun of it and to get an idea what the minimal size of the userbase is.

[17-may-2007]
After lot's of testing I have finally submitted the new version 1.8.2
- all reported bugs and annoyances are fixed
- backups are now stored in a single location (/var/lib/cfg-update/backups)
- alias for emerge has been replaced by hooks for Portage and Paludis
- added support for package manager Paludis
- added support for mergetool imediff2
- cfg-update can now update multiple hosts from a single location! (see /etc/cfg-update.hosts)
Warning: if you have used Paludis <0.20.0, you need to run cfg-update --check-packages
and follow the instructions! Due to a "bug" in the older versions of Paludis you risk losing
custom settings in the configuration files, belonging to packages that were installed with
Paludis <0.20.0, when using cfg-update.
Thanks go out to the users who have contributed new ideas and especially zxy for helping me
with the Paludis issues!

[16-mar-2007]
Just noticed that the package is added as unstable for sparc.

[10-mar-2007]
Version 1.8.0-r6 is now also stable on ppc.

[03-mar-2007]
Finally cfg-update-1.8.0-r6 has been marked stable for x86 and amd64!
A minor change was made to the ebuild, it now places a line in /etc/cfg-update.conf that
sets the location of the checksum-index to: /var/lib/cfg-update/checksum.index

[02-feb-2007]
Update to version 1.8.0-r6 with fix for bug #164986.
I've put the GUI-check in a separate subroutine that is only called from
within the update_files subroutine, and only if the -a or -p flag is not found.
So "cfg-update -l" now works when GUI is not available, no message is displayed.
"cfg-update -au" now works when GUI is not available because automatic-only-updating
doesn't need a GUI. "cfg-update -pu" now works when GUI is not available because
pretend-update doesn't need a GUI. It will only display the message and exit if the GUI
is not available when running "cfg-update -u".
Thanks Balint for reporting this issue!

[21-jan-2007]
Update to version 1.8.0-r5 with some minor bugfixes.
The script now uses grep instead of cat to get information from files.
The script now uses /var/log/emerge.log instead of /var/log/portage to determine
the last installed package. Added two new options, the first removes unnecessary
backup files from previous updates. This leaves the backups from modified files
so that 3-way merging is possible on future updates. The second option completely
removes all backup files from previous updates which is usefull when permanently
uninstalling cfg-update. Also added vimdiff and gvimdiff support. The alias for emerge
that calls the wrapperscript (cfg-update --on) is now set in /root/.bashrc and not in
/etc/profile anymore. And the bug that caused problems when using meld in combination
with stage 2 (automatic 3-way merging) has been fixed. If there is a merge-conflict
the .merge file will be deleted so meld can happily update the files in stage 3/4.
Sorry it took so long to release this update!

[12-jan-2006]
Update to version 1.8.0-r3 with a bugfix for first-time installs. After the first install
cfg-update would not create the checksum-index if there are any ._cfg0000_files to
prevent unmodified files to be shown as modified. But because the checksum-index
isn't created, cfg-update can't determine the modification state of the current config
file. So you get a catch-22 where files can't be updated with cfg-update until all files
have been updated. I now force index creation (empty) during the "cfg-update --on"
phase of the install. This forced index makes cfg-update handle all files as modified
files, thus forcing a manual merge on all of them. After updating all files with cfg-update
the index will become usable for autoupdates on next sessions...
Thanks Alexio for reporting this!

[11-jan-2006]
Update to version 1.8.0-r2 with various bugfixes. It now correctly handles updates of
executable files (it didn't set executable bit on scripts in /etc/init.d)
It reads the enable_backups setting correctly now, the --fix option has been removed
and the alias is now stored in /root/.bashrc because this file is always sourced on login.
It also no longer restores the MD5 when restoring backups bacause that caused the
restored files to be handled as if they were unmodified even if they contained custom
settings. It now forces you to manually update restored files.
And I did some cosmetic changes...

[03-jan-2006]
Update to version 1.8.0-r1 with various small bugfixes...

[01-jan-2006]
Happy newyear and the best wishes to all!
Released version 1.8.0 with some major changes. It now can handle automatic 3-way
merging, the indexing has improved to avoid unnecessary lag during emerge commands.
It now also keeps it's configuration settings in /etc/cfg-update.conf and the alias
for emerged has been moved to /root/.bash_profile

[30-sep-2005]
Added instructions for speeding up emerge output with a PHP script. Thanks go out to
tightcode for creating the script! I will try to implement a permanent solution to the
next version.

[14-sep-2005]
Added instructions for creating a KDE menu item for cfg-update. Thanks go out to
Sheepdogj15 for sharing this tip!

[08-sep-2005]
Released version 1.7.2 to fix a minor bug with handling variables with extra spaces
in /etc/make.conf. It now uses portageq, which is a bit slower, for reading the variables.

[29-apr-2005]
Released version 1.7.1 as a masked package in the portage tree...
Big thanks go to Harald van Dijk (aka truedfx) !!!

[26-apr-2005]
Posted a beta version of 1.7.1 and a modified ebuild in Bugzilla for testing.

[29-jan-2005]
Changed the version 1.7 ebuild to fix two bugs...
The dependency for meld had a typo and the ebuild should not disable the alias
when it's being unmerged. Otherwise the checksums will not be updated any
longer. (old version is unmerged after new version is installed, so if the old ebuild
disables the alias, the new ebuild cannot turn it on because it has finished before
the old ebuild does this... hard to explain)

[24-jan-2005]
Version 1.7 released. It's now easier to make it work with meld or other tools.
The ebuild now uses USE-flags, if you want to use it with xxdiff you need to
have either "kde" or "qt" enabled and if you want to use meld you need the "gnome"
flag.

[22-jul-2004]
Textutils are now included in the coreutils package, changed the dependency
in the ebuild. Thanks yngwin for reporting it!

[26-feb-2004]
Location of tarball has changed. Ebuild does not automatically convert your old
backups to the new filename format anymore. You should run (as root):
/usr/lib/cfg-update/convert.sh
The ebuild has been updated accordingly.

[17-feb-2004]
Added the "Important note" section to this page. The alias in /etc/profile
needs to be temporarily turned off if you need USE flags for emerging a
package.

[11-feb-2004]
Changed the version 1.6 tarball on the server to fix a small bug.

[10-feb-2004]
Version 1.6 released. Submitted a new ebuild. Still waiting...
The filename format for the backups has been changed because of problems with
the init scripts during startup (/etc/init.d) The files are now saved as ._new-cfg_*
and ._old-cfg_* ! This prevents the files from being executed on startup.
The ebuild takes care of renaming your old backups...

[12-jan-2004]
Version 1.5 released. Submitted a new ebuild. Still waiting for an official placement
in the main portage tree. The script now uses strict, and contains a bugfix. The
script now checks if the original config file was executable and sets the updated
config file accordingly. It correctly handles init scripts now. (in /etc/init.d/)
Note: you should check if all files in /etc/init.d/ are executable. If they are
not, please "chmod +x" them... You can do this (as root) like this:

[08-dec-2003]
Version 1.4 released. Submitted a new ebuild. I'm still wondering when it will
finally be added to the Portage tree... cfg-update has a new automerge option
which is "on" by default as it is totally safe and really speeds up the updating
process! All unmodified and binary files are updated (and backup'ed) automatically.
Added support for updating binary files... I had totally forgotten about the binary
files (like /etc/X11/xdm/chooser) but cfg-update can handle them correctly now,
allowing you to overwrite the current file with the new file.

[19-nov-2003]
Version 1.3 released. Submitted a new ebuild... I wonder how long it takes
to make it an official package. The ebuild now does all the dirty installation work
by itself. Minor changes to the script, see ChangeLog included in the tarball.

[13-nov-2003]
Added support for more terminal types; xterm, eterm, Eterm, rxvt and aterm
should all use the GUI tool by default... (please report if one of the types does
not work with the GUI tool, then I'll change it to use the CLI tool instead)

[11-nov-2003]
Added more verbose info when portage logdir is not found in /etc/make.conf

[09-nov-2003]
Minor fix to filter out quotes when portage logdir is read from file...

[04-nov-2003]
Version 1.2 released. (ebuild submitted) Fixed some small bugs and made a
structural change: you now have to "save as merged..." in xxdiff!
This has changed to make updates the same for the GUI and CLI mode.
It also can fix your root environment with the --check option.
The ebuild should be in app-portage/cfg-update soon!

[29-oct-2003]
Version 1.1 released. Made the overwrite function safer by only allowing it for
unmodified config files. This meant that I had to integrate cfg-update with the
emerge command (see FAQ for explanation) Added package search function,
command line (CLI) mode so it can do the same manual merging with sdiff as
etc-update. Plus some minor bugfixes and layout changes...

[21-oct-2003]
Version 1.0 is now available for download. It has a new overwrite function and
the backups can be easily restored. Because I added new functions I had
to rename some options, -i changed to -u. Sorry, it won't happen again!
An ebuild is being worked on...

[19-oct-2003]
The script is no longer shown in this post, just download it.

[18-oct-2003]
The MergedView and Toolbar are now turned on by default and the style is
set to Keramik. Just figured out how to turn these on from the cmdline thanks to
another post on the Gentoo Forums...

[13-oct-2003]
You can now configure the script with the -c option so it operates in a
preferred mode, turn on/off backing up of the config files and select the default editor.

[12-oct-2003]
Added more options and optimized some code. Renamed the script to
cfg-update and rewrote this post...

[11-oct-2003]
Minor changes, added another option that shows all the protected dirs on your system.

[19-sep-2003]
The script now automatically finds all protected config dirs on your system, the
defaults are stored in /etc/make.globals and others can be read from the CONFIG_PROTECT
environment variable.

[18-sep-2003]
Added a couple of lines so it asks if you'd like to delete the ._cfg????_ file when
you're done diffing/merging the files. Added explanation for xxdiff._________________When all else fails, read the manual...
Registered Linux User #340626

Last edited by xentric on Thu Nov 27, 2008 11:47 pm; edited 156 times in total

this is just an option for those who do
not want to edit to their etc-update file
and set xxdiff there, but just want a
quick paste-to-a-file and use script to
use to update their files using a nice
graphical interface.

so in short, the answer to your question
would be: it buys you time you might
spend on modifying etc-update.conf.

though if you do not see why you
might want to use this, just don't use
it that's the nice thing about linux.
everything is just an option, hardly
anything is forced on you.

or at least, that's what i'd say._________________proud to be a scout and a chronic penguin hugger
Legion of Lore - site

Not to rain on your parade, but what does this buy me over editing /etc/etc-update.conf?

First of all, for me this was a good way to learn coding in perl...
As neenee mentioned you don't have to edit etc-update.conf and it doesn't have confusing
automerge options. Just read all the posts about people wiping their config files by using
etc-update incorrectly.

It makes backups of the old and new files, shows you all protected directories or prints
a list with all the ._cfg????_ files that have to be updated.

If you would like to see a feature added, just post your wishlist and I'll see what I can
do to make it work for you...

xentric: how easy would it be to change your script to use a choice of graphical merge tools - e.g. choice of tkcvs, meld, xxdiff? Perhaps by a config file?

Uhhm... it can do that already!
Just type "cfg-update -c" and you can set the editor to /usr/bin/tkdiffb
It doesn't need a config file, the script rewrites itself
Maybe I should add a feature that allows the user to adjust the way the
diff tool is being called. So you can supply options and stuff...

There's also a request to include a [r]eplace option, so you can replace
the old config file with the new ._cfg????_ file instead of opening the diff
tool. I will add that in the next couple of days!

Last edited by xentric on Wed Oct 22, 2003 6:03 pm; edited 1 time in total

Thank-you for the script creation... please get it into the portage system.

Thanks

Thanks

I'm working an improved version which will hopefully be worthy of an
ebuild. The new version is almost finished and will be able to undo updates
that you have done with the script.
But I still have to figure out how to build and submit an ebuild, I took a
quick glance at the ebuild Doc and hopefully I can have it ready in one
or two days.

Very cool project! I may give this a try as soon as my computer recovers from the effort of splitting the support posts into troubleshooting cfg-update.._________________if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..

You will need to run jedit as root, and have the jdiff plugin installed.

I have not spent a lot of time on this, just got it to "good enough for me state" but am willing to put in some more time if anyone wants.

I really want to extend it to allow for a daemon making config requests from multiple machines to a single client, to allow easy config management of many boxen, headless boxen etc._________________.sigless since 2002

Does anyone know a small package that I can use as an example for creating an ebuild ?
It doesn't need to compile, just copy the cfg-update script to /usr/local/bin
But it does have a couple of dependencies:
- perl
- xxdiff
- gentoolkit
- xfree (otherwise you can only use it in CLI mode)

Painful or not, you probably didn't look at the solution for your problem...

Quote:

Error:bash: cfg-update: command not found

If you get this error when trying to run cfg-update when su'ed to root:
Check if /root/.bashrc and /root/.bash_profile exist. If they are missing,
copy them from /etc/skel to the /root dir. Then add these two lines to
/root/.bashrc :

And... if you run cfg-update in a virtual terminal, it cannot launch the graphical
tool and therefore it uses the sdiff tool instead (just like etc-update). You
should run it from an xterm, konsole, aterm, eterm... whatever terminal type
you choose, as long as the environmental variable TERM=xterm. Otherwise it
can not use the GUI diff tool !
You can check this by typing:

Version bump... 1.4 with automerging for unmodified and binary files.
It will prompt for modifed files, but automatically updates the files that
don't need to be manually merged... and it's safe!
Updating large batches of updated config files can't get much easier