# app-portage/cfg-update - installation instructions

## xentric

LAST UPDATE: 11-07-2008 (see changelog below)

Note: questions, feedback, suggestions and bug-reports can be posted

in this thread: app-portage/cfg-update - troubleshooting...

******************************************************************************

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...

Send me a private message if you're interested in adopting cfg-update.

Regards,

Stephan van Boven

******************************************************************************

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:

```
echo app-portage/cfg-update ~x86 >> /etc/portage/package.keywords
```

(The "ACCEPT_KEYWORDS=~arch" flag shouldn't be used for installing masked ebuilds!

Please read this excellent post on How to use portage correctly

or read the Gentoo Handbook Chapter 3. Mixing Software Branches...)

2. Now install cfg-update:

```
emerge -av cfg-update
```

3. Log out and use sux (or su) to become root again:

```
exit

sux

(enter password)
```

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:

```
"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".

Basic usage commands:

```
"cfg-update" Shows the help page with commands

"cfg-update -l" Listing of all updates on localhost only

"cfg-update -l -h0" Listing of all updates on localhost only

"cfg-update -l -h1" Listing of all updates on remote host nr 1

"cfg-update -l -h1-100" Listing of all updates on remote hosts nr 1 to 100

"cfg-update -l -h0-100" Listing of all updates on localhost and remote hosts nr 1 to 100

"cfg-update -v -l" Verbose listing of all updates

"cfg-update -p -u" Pretend update session

"cfg-update -u" Start updating session for localhost only

"cfg-update -u -h0" Start updating session for localhost only

"cfg-update -u -h1" Start updating session for remote host nr 1

"cfg-update -u -h1-100" Start updating session for remote host nr 1 to 100

"cfg-update -u -h0-100" Start updating session for localhost and remote host nr 1 to 100

"cfg-update -u -t xxdiff" Start updating session and use xxdiff for merging

"cfg-update -u -t kdiff3" Start updating session and use kdiff3 for merging

"cfg-update -u -t meld" Start updating session and use meld for merging

"cfg-update -u -t gtkdiff" Start updating session and use gtkdiff for merging

"cfg-update -u -t gvimdiff" Start updating session and use gvimdiff for merging

"cfg-update -u -t tkdiff" Start updating session and use tkdiff for merging

"cfg-update -u -t sdiff" Start updating session and use sdiff for merging (non-GUI)

"cfg-update -u -t imediff2" Start updating session and use imediff2 for merging (non-GUI)

"cfg-update -u -t vimdiff" Start updating session and use vimdiff for merging (non-GUI)

... or permanently change the tool in /etc/cfg-update.conf

"cfg-update -v -u" Start updating session (unhides STDERR messages for troubleshooting)

"cfg-update -u -a" Start updating session (only do the automatic updates)

"cfg-update -u -m" Start updating session (disables automatic updates)

"cfg-update -b" Listing of all backups of previous updates (including date)

"cfg-update -b | grep 2006-07" Verbose listing of all backups from updates in July 2006

"cfg-update -r 17" Restore both files of number 17 in the listing of backups

"cfg-update --mount" Mount remote systems with SSHFS specified in /etc/cfg-update.hosts

"cfg-update --check" Check mounted remote systems specified in /etc/cfg-update.hosts

"cfg-update --unmount" Unmount remote systems specified in /etc/cfg-update.hosts
```

Other commands:

```
"cfg-update --index" Update the checksum index (is executed by Portage hook)

"cfg-update --index --paludis" Update the checksum index (is executed by Paludis hook)

"cfg-update --force --index" Force updating of the checksum index (not recommended for normal usage!)

"cfg-update --optimize-backups" Creates backups of unmodified files to maximize future automatic updates

"cfg-update --check-packages" Checks packages installed with Paludis <0.20.0 (recommended for Paludis users!)

"cfg-update --disable-portage-hook" Disable hook for Portage (is done during uninstall)

"cfg-update --disable-paludis-hook" Disable hook for Paludis (is done during uninstall)

"cfg-update /etc/fileA /etc/fileB" Alternative for 2-way merging of other files

"cfg-update /etc/fileB /etc/fileA /etc/fileC" Alternative for 3-way merging of other files

"cfg-update -s" Show all protected directories

"cfg-update -d -l" Debug mode enabled for listing of updates (shows subroutine tags)

"cfg-update -d -u" Debug mode enabled for updating (shows subroutine tags)
```

Usage info (including screenshots)

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...

Screenshot cfg-update 1

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.

Screenshot cfg-update 2

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.

Screenshot xxdiff

Screenshot kdiff3

Screenshot meld

Troubleshooting

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:

```
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:

```
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:

```
stage 1 - automatic replacing of files with state 3,4

stage 2 - automatic 3-way merging with diff3 of files with state 1,3 (and backup of previous update is available)

stage 3 - manual 3-way merge with preferred tool of files with state 1,3 (and backup of previous update is available)

stage 4 - manual 2-way merge with preferred tool of files with state 1,3,5

stage 5 - manual (interactive) update of files with state 2,4,6,7,8,9
```

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...  :Rolling Eyes: 

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:

```
root@yourbox / # for i in `find /etc/init.d -perm 644`; do chmod +x $i; done
```

[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.

----------

## meowsqueak

Nice script. I think etc-update searches all subdirectories under /etc, since 'emerge --help config' shows this command: 

```
# find /etc -iname '._cfg????_*'
```

Here's another alternative - if you emerge the excellent CVS front-end 'tkcvs' you get a nice GUI diff/merge tool for free called tkdiffb. Now, change two lines in /etc/etc-update.conf as follows:

```
diff_command="tkdiffb %file1 %file2"

merge_command="tkdiffb %orig %new -o %merged"
```

Cool huh?   :Cool: 

----------

## xentric

 *meowsqueak wrote:*   

> Nice script. I think etc-update searches all subdirectories under /etc, since 'emerge --help config' shows this command: 
> 
> ```
> # find /etc -iname '._cfg????_*'
> ```
> ...

 

Well, I'm pretty sure I've seen files listed in /usr/kde/ and /usr/X11R6/ so I've included these dirs too.

 *Quote:*   

> 
> 
> Here's another alternative - if you emerge the excellent CVS front-end 'tkcvs' you get a nice GUI diff/merge tool for free called tkdiffb. Now, change two lines in /etc/etc-update.conf as follows:
> 
> ```
> ...

 

I'm emerging it now to see how it works  :Smile: 

Edit: Tried it with tkdiffb successfully, after emerging tkcvs run "cfg-update -e"

and type: tkdiffb

Maybe I'll start using tkdiffb instead of xxdiff myself...Last edited by xentric on Wed Sep 24, 2003 10:17 pm; edited 2 times in total

----------

## water

I'm not sure, but i thought there is an option in /etc/make.conf, where you can set wich directory's will be not updated automaticly.

----------

## irasnyd

Yeah, there is a value in /etc/make.conf so that you can add additional directories to protect.  I'm pretty sure you should be able to extract it from there somehow.

----------

## xentric

Ah... it's in /etc/make.globals

```
xentric@gentoo / $ cat /etc/make.globals | grep CONFIG_PROTECT=

CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config"

```

and more with:

```
xentric@gentoo / $ env | grep CONFIG_PROTECT=

CONFIG_PROTECT=/usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config

```

I'll update the script asap to automatically use the correct dirs !

Thanks  :Smile: 

Edit: Done!

----------

## hythl0day

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

----------

## neenee

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  :Smile:  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.

----------

## xentric

 *hythl0day wrote:*   

> 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...

----------

## meowsqueak

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?

----------

## xentric

 *meowsqueak wrote:*   

> 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   :Cool: 

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

----------

## abclements

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

Thanks

----------

## xentric

 *abclements wrote:*   

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

 Thanks  :Very Happy: 

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.

----------

## masseya

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..

----------

## des09

I have a small jedit plugin that I use for finding and merging config files, it is available at http://sourceforge.net/projects/jediconfig/

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.

----------

## xentric

Version 1.1 is now ready download...

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)

----------

## smith

```
root@gentoo bin # chmod 755 cfg-update 

root@gentoo bin # cfg-update --on

bash: cfg-update: command not found

```

i get this error everytime.. whats the problem??

----------

## xentric

 *Quote:*   

> i get this error everytime.. whats the problem??

 

Please read the troubleshooting section in the post above...

It's the first error mentioned!

----------

## smith

ok.. after looking through those 4 painful pages I came up with the following:

```
root@gentoo bin # perl cfg-update --on

use of uninitialized value in concatenation (.) or string at cfg-update line 643

Portage Logdir: not found... Edit /etc/make.conf  !
```

So I added the logdir.. and it started up when I issue the command:

```
perl cfg-update -u
```

however, I don't see anything graphical.. looks a lot like etc-update .. i did update a few files.. and when I hit "y" nothing lauched as in the faq above..

----------

## xentric

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,
> ...

 

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: 

```
env | grep ^TERM=
```

Note: if you still cannot get it to work, please post your questions in this thread:

Troubleshooting cfg-update...

----------

## smith

ok..its is working now... very nice scipt.. i update over 50 files in about an hour.. 

thx again

----------

## dabi_du

I get the folowing reply after "cfg-update --check"

```
matt bin # cfg-update --check

Portage Logdir:  not found... Edit /etc/make.conf !

```

I have no idea what to change in make.conf.

Any sugestion please.

----------

## xentric

Dabi_du, look here for a reply to your question...

(the Doc, Tip & Tricks Forum is not a support forum)

----------

## xentric

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   :Very Happy: 

----------

## dabooty

i love this, thank you very much xentric

----------

## raptor

does anyone know for a similar tool which doesn't use Qt .. thanx

----------

## charlieg

I don't mind the use of Qt, but why the hell do I need kdelibs?

----------

## xentric

Here are the dependencies for xxdiff, the graphical diff/merge tool that cfg-update uses

by default:

```

DEPEND=">=x11-libs/qt-3.0.0

    =dev-util/tmake-1.8*

    kde? ( >=kde-base/kdelibs-3.1.0 )"
```

Why does it need kdelibs? Probably because you already have kde installed and it just

wants a newer version of kdelibs.

You can ' emerge -i xxdiff ', which makes portage think that it has installed xxdiff already.

This way it probably doesn't need QT or newer Kdelibs when you install cfg-update, but I

haven't tried this myself...

----------

## xentric

version 1.5 is out, see changes in changelog (bottom of first post in this thread)

----------

## rberry88

I'm having trouble getting cfg-update to recognize the /var/log/portage/ directory that I made.

I did the steps in the first post but when I try to run it I get this:

```
root@tux rberry88 # cfg-update

Portage Log not found...

Enable PORT_LOGDIR in /etc/make.conf

Recommended: PORT_LOGDIR=/var/log/portage

Make sure the directory exists!

```

My make.conf file:

```

root@tux rberry88 # cat /etc/make.conf

# Copyright 2000-2002 Daniel Robbins, Gentoo Technologies, Inc.

# Contains local system settings for Portage system

# Please review 'man make.conf' for more information.

 

# Build-time functionality

# ========================

#

# The USE variable is used to enable optional build-time functionality. For

# example, quite a few packages have optional X, gtk or GNOME functionality

# that can only be enabled or disabled at compile-time. Gentoo Linux has a

# very extensive set of USE variables described in our USE variable HOWTO at

# http://www.gentoo.org/doc/use-howto.html

#

# The available list of use flags with descriptions is in your portage tree.

# Use 'less' to view them:  --> less /usr/portage/profiles/use.desc <--

#

# Example:

#USE="X gtk gnome -alsa"

USE="gnome gtk -kde -qt"

USE="qt kde -gnome -gtk"

USE="cups"

 

# Host Setting

# ============

#

# If you are using a Pentium Pro or greater processor, leave this line as-is;

# otherwise, change to i586, i486 or i386 as appropriate. All modern systems

# (even Athlons) should use "i686-pc-linux-gnu"

#

CHOST="i686-pc-linux-gnu"

 

# Host and optimization settings

# ==============================

#

# For optimal performance, enable a CFLAGS setting appropriate for your CPU

#

# -mcpu=<cpu-type> means optimize code for the particular type of CPU without

# breaking compatibility with other CPUs.

#

# -march=<cpu-type> means to take full advantage of the ABI and instructions

# for the particular CPU; this will break compatibility with older CPUs (for

# example, -march=athlon-xp code will not run on a regular Athlon, and

# -march=i686 code will not run on a Pentium Classic.

#

# CPU types supported in gcc-3.2 and higher: athlon-xp, athlon-mp, athlon-4,

# athlon-tbird, athlon, k6, k6-2, k6-3, i386, i486, i586 (Pentium), i686

# (PentiumPro), pentium, pentium-mmx, pentiumpro, pentium2 (Celeron), pentium3,

# and pentium4. Note that Gentoo Linux 1.4 and higher include at least gcc-3.2.

#

# CPU types supported in gcc-2.95*: k6, i386, i486, i586 (Pentium), i686

# (Pentium Pro), pentium, pentiumpro Gentoo Linux 1.2 and below use gcc-2.95*

#

# Decent examples:

#

#CFLAGS="-mcpu=athlon-xp -O3 -pipe"

CFLAGS="-O2 -march=athlon-xp -pipe"

 

# If you set a CFLAGS above, then this line will set your default C++ flags to

# the same settings. If you don't set CFLAGS above, then comment this line out.

CXXFLAGS="${CFLAGS}"

 

# Advanced Masking

# ================

#

# Gentoo is using a new masking system to allow for easier stability testing

# on packages. KEYWORDS are used in ebuilds to mask and unmask packages based

# on the platform they are set for. A special form has been added that

# indicates packages and revisions that are expected to work, but have not yet

# been approved for the stable set. '~arch' is a superset of 'arch' which

# includes the unstable, in testing, packages. Users of the 'x86' architecture

# would add '~x86' to ACCEPT_KEYWORDS to enable unstable/testing packages.

# '~ppc', '~sparc', '~sparc64' are the unstable KEYWORDS for their respective

# platforms. DO NOT PUT ANYTHING BUT YOUR SPECIFIC ~ARCHITECTURE IN THE LIST.

# IF YOU ARE UNSURE OF YOUR ARCH, OR THE IMPLICATIONS, DO NOT MODIFY THIS.

#

#ACCEPT_KEYWORDS="~arch"

 

# Portage Directories

# ===================

#

# Each of these settings controls an aspect of portage's storage and file

# system usage. If you change any of these, be sure it is available when

# you try to use portage. *** DO NOT INCLUDE A TRAILING "/" ***

#

# PORTAGE_TMPDIR is the location portage will use for compilations and

#     temporary storage of data. This can get VERY large depending upon

#     the application being installed.

#PORTAGE_TMPDIR="/var/tmp"

#

# PORTDIR is the location of the portage tree. This is the repository

#     for all profile information as well as all ebuilds. This directory

#     itself can reach 200M. WE DO NOT RECOMMEND that you change this.

#PORTDIR="/usr/portage"

 

# PORT_LOGDIR is the log where any error messages are store when emerge fails

#      and when you do cfg-update it will store the changes here

PORT_LOGDIR=/var/log/portgage

 

# DISTDIR is where all of the source code tarballs will be placed for

#     emerges. The source code is maintained here unless you delete

#     it. The entire repository of tarballs for gentoo is 9G. This is

#     considerably more than any user will ever download. 2-3G is

#     a large DISTDIR.

#DISTDIR="${PORTDIR}/distfiles"

#

# PKGDIR is the location of binary packages that you can have created

#     with '--buildpkg' or '-b' while emerging a package. This can get

#     upto several hundred megs, or even a few gigs.

#PKGDIR="${PORTDIR}/packages"

#

# PORTDIR_OVERLAY is a directory where local ebuilds may be stored without

#     concern that they will be deleted by rsync updates. Default is not

#     defined.

PORTDIR_OVERLAY="/usr/local/portage"

 

# Fetching files

# ==============

#

# If you need to set a proxy for wget or lukemftp, add the appropriate "export

# ftp_proxy=<proxy>" and "export http_proxy=<proxy>" lines to /etc/profile if

# all users on your system should use them.

#

# Portage uses wget by default. Here are some settings for some alternate

# downloaders -- note that you need to merge these programs first before they

# will be available.

#

# Lukemftp (BSD ftp):

#FETCHCOMMAND="/usr/bin/lukemftp -s -a -o \${DISTDIR}/\${FILE} \${URI}"

#RESUMECOMMAND="/usr/bin/lukemftp -s -a -R -o \${DISTDIR}/\${FILE} \${URI}"

#

# Prozilla (turbo downloader)

#FETCHCOMMAND='/usr/bin/proz --no-getch -s ${URI} -P ${DISTDIR}'

 

# Advanced Features

# =================

#

# MAKEOPTS provides extra options that may be passed to 'make' when a

#     program is compiled. Presently the only use is for specifying

#     the number of parallel makes (-j) to perform. The suggested number

#     for parallel makes is CPUs+1.

#MAKEOPTS="-j2"

#

# AUTOCLEAN enables portage to automatically clean out older or overlapping

#     packages from the system after every successful merge. This is the

#     same as running 'emerge -c' after every merge. Set with: "yes" or "no".

#AUTOCLEAN="yes"

#

# FEATURES are settings that affect the functionality of portage. Most of

#     these settings are for developer use, but some are available to non-

#     developers as well. 'buildpkg' is an always-on setting for the emerge

#     flag of the same name. It causes binary packages to be created of all

#     packages that are merged.

#FEATURES="sandbox ccache buildpkg"

#

# RSYNC_RETRIES sets the number of times portage will attempt to retrieve

#     a current portage tree before it exits with an error. This allows

#     for a more successful retrieval without user intervention most times.

#RSYNC_RETRIES="3"

GENTOO_MIRRORS="ftp://ibiblio.org/pub/Linux/distributions/gentoo/ http://www.gtlib.cc.gatech.edu/pub/gentoo"

root@tux rberry88 #

```

and here is the /var/log/portage directory:

```

root@tux rberry88 # cd /var

root@tux var # ls

cache  cvsroot  db  ekpd  empty  lib  lock  log  mail  run  spool  state  tmp

root@tux var # cd log

root@tux log # ls

XFree86.0.log      XFree86.8.log.old  genkernel.log  messages  scrollkeeper.log

XFree86.0.log.old  cups               kdm.log        news      wtmp

XFree86.8.log      emerge.log         lastlog        portage   xdm.log

root@tux log # cd portage

root@tux portage #

```

I'm not sure what to try next, I looked at the posts in the other threads also and haven't been able to move forward.

Any help is appreciated.

rberry88

----------

## OrezzerO

Any way to use the CLI version w/o installing X?

I would love to try this but do *not* want to emerge X11*

Thanks,

-Jeff

----------

## xentric

 *OrezzerO wrote:*   

> Any way to use the CLI version w/o installing X?
> 
> I would love to try this but do *not* want to emerge X11*

 

There are a couple of ways of doing this. You can either "inject" xxdiff with "emerge -i xxdiff"

or just remove the xxdiff dependency from the ebuild file after saving it in your portage

overlay directory. Both methods have the same effect, xxdiff won't be installed, hence no need

for X11*

----------

## meowsqueak

When I try the 'ebuild /usr/local/portage/app-portage/cfg-update/cfg-update-1.5.ebuild digest' command, it tries (unsuccessfully) to get this file:

>>> Downloading http://gentoo.oregonstate.edu/distfiles/cfg-update-1.5.tar.gz

I simply downloaded your 1.5 ebuild and I'm following your instructions.

----------

## yuza

Hi Xentric! I would like to make a little suggestion to improve this already wonderful program... I've noticed that cfg-update saves the merged files and the backup version as foo.newcfg and foo.oldcfg respectively. I've noticed that this causes some problems with the init scripts because the .oldcfg and .newcfg are recognised and started at boot time. For example I had checkroot, checkroot.newcfg, and checkroot.oldcfg in my /etc/init.d. This caused a circular dependencies problem of type ibefore because the two backup files were recognised along with checkroot and therefore none of them wanted to start because checkroot has to start before everything. I also had a simliar problem with alsa because alsasound.oldcfg and alsasound.oldcfg wanted to start after alsasound and this off course caused some warnings at boot time. Off course the soultion is simple: you just have to remove the .oldcfg and.newcfg after having verified that the updated file works. I was wondering if it would be possible to have cfg-update save the backup copies with different names... I mean names which are not recognized at boot time. This would allow to keep the backup version of the file without the little annoyances I explained before. 

Just a suggestion....

----------

## meowsqueak

Or how about putting all the backups in a directory by themselves?

----------

## xentric

I'm working on a solution for this... will post & upload it soon!

----------

## xentric

You're right, it should not place backups in /etc/init.d/ without putting a . infront of them!

I kinda expected such situations, like portage switching filename formats or conflicts with

different software saving files with the same extensions. So I already had coded a filename

formatting solution for easy changes in the future...

So the solution is simple, just change the filename patterns from:

```
version 1.5

# defining patterns... (line 57)

    my $config_new  = "._cfg????_*";

    my $rm_new      = "\\._cfg\\d+_";

    my $backup_old  = "*.oldcfg";

    my $restore_old = "*";

    my $rm_old      = "\\.oldcfg";

    my $backup_new  = "*.newcfg";

    my $restore_new = "._cfg0000_*"; 

    my $merged      = "*.merge";
```

to:

```
version 1.6

# defining patterns... (line 57)

    my $config_new  = "._cfg????_*";

    my $rm_new      = "\\._cfg\\d+_";

    my $backup_old  = "._old-cfg_*";

    my $restore_old = "*";

    my $rm_old      = "\\._old-cfg_";

    my $backup_new  = "._new-cfg_*";

    my $restore_new = "._cfg0000_*";

    my $merged      = "*.merge";
```

Now the backups are being saved as ._old-cfg_filename and ._new-cfg_filename

The . hides the files and prevents them from being started just like portage hides the

updated files with ._cfg0000_filename.

But after making these changes you should run this oneliner to rename all old backups:

```
for i in `find / -iname *.oldcfg`; do j=$(dirname $i); k=$(basename $i | sed 's/.oldcfg//'); echo "Renaming $i -> $j/._old-cfg_$k"; `echo "mv $i $j/._old-cfg_$k"`; done ; for i in `find / -iname *.newcfg`; do j=$(dirname $i); k=$(basename $i | sed 's/.newcfg//'); echo "Renaming $i -> $j/._new-cfg_$k"; `echo "mv $i $j/._new-cfg_$k"`; done
```

You can skip the above by simply installing the new version (1.6) which includes the new

._old-cfg_ and ._new-cfg_ filename format for backups. The ebuild also takes care of the

filename conversion of all backup files to the new format!

The problem I have with putting all backups in a single directory, is that it get's a lot harder

to simply restore the backup. I have to include it's original location in the backupfile itself.

Then after restoring I have to remove this info from the file. It doesn't make it easier for

someone who tries to manually restore files either. There are plenty ways to do this, but I

think the above solution is clean and simple...

If you really don't want the backups cluttering your /etc directory, you can always think up

alternative ways to be safe. A simple example:

Turn off backups in the settings screen by running "cfg-update -c"

Then make a cronjob that makes a daily or weekly backup of /etc

(which is a good idea anyway!)

----------

## meowsqueak

 *xentric wrote:*   

> The problem I have with putting all backups in a single directory, is that it get's a lot harder
> 
> to simply restore the backup. I have to include it's original location in the backupfile itself.
> 
> Then after restoring I have to remove this info from the file. It doesn't make it easier for
> ...

 

I'm not trying to be difficult, and I think you've created a great tool, but you could always have a directory somewhere (/etc/cfg-backups for example) that has a 'mirror' structure of /etc (just directories) and you store the backups in the relevant place. Using a hidden file is probably adequate however    :Smile: 

So where do we get ebuild 1.6 from? I had no luck installing 1.5 so I'm looking out for one that works   :Wink: 

----------

## xentric

I'm working on 1.6 right now. There's one thing I still have to test

so please wait and do not yet manually change the stuff mentioned in

my previous post!

The new ebuild will be posted in a couple of hours... (if I don't encounter

more problems while testing it)

I'll keep the 'mirror' structure in mind, if I figure out a simple way to

implement that, it will probably be in the next (1.7) version.

----------

## xentric

version 1.6 released, go check the first post of this thread.

please report back if you have any problems with the ebuild

or the filename conversion which is done by the ebuild...

Edit: I'm having problems getting the tarball downloaded to my machine.

I don't have time to troubleshoot this at the moment, so if you have the

same problem, I'll post again as soon as I have fixed it. (24-48hrs.)

Sorry

----------

## yuza

Thank you so much for all this work you are doing Xentric. I relly hope that cfg-update will be added to the portage tree very soon. A lot of posts in this forum are related to problems with etc-update, a tool like cfg-update is very needed I think... it'a addition to portage will clean up this fourm from all those duplicate threads about etc-update!!

----------

## mlybarger

this sounds like a really nice tool. i really hope i'm doing something wrong. etc-update shows me currently 26 files for update, but cfg-update -u shows me it finds no files. i'm using the 1.6 version.

```

bash-2.05b$ su -l

Password:

expresso mark # cfg-update --check

----------

## pross

same problem here  :Sad: 

 *Quote:*   

> 
> 
> * GNU info directory index is up-to-date.
> 
>  * IMPORTANT: 23 config files in /etc need updating.
> ...

 

 *Quote:*   

> 
> 
> Gentoo pross # cfg-update --check
> 
> 

----------

## infamousmrsatan

me too.  any ideas?  I have 118 config files to clean up, and do NOT want to use etc-update   :Confused:    But cfg-update doesn't see any of them.

----------

## mlybarger

um, you could try an older version until xentric has time to check into this.  a more challenging route would be to debug it yourself and see what's going on. personally, i just used etc-update and will continue to watch this thread.  

though also, if you search on the forums, there are other tools doing similar thing (auto clean files that you haven't touched).  that's what _most_ etc files are, and i'd gather that 99% of the updates in etc-udpate are untouched files.  

imo, portage itself needs the ability to auto update files the user hasn't touched personally or through an application.

----------

## infamousmrsatan

 *mark_lybarger wrote:*   

> 
> 
> imo, portage itself needs the ability to auto update files the user hasn't touched personally or through an application.

 

I agree.  It seems like portages is just slogging us with extra work in this instance.

I'll wait a few days and see if there's any action on this before I go looking elsewhere...

Justin

----------

## xentric

Update:  I have been able to fix the tarball on the server !

You can unmerge cfg-update and merge it again...

I don't know what effect a changed tarball has on portage, so please

remove all files from /usr/local/portage/app-portage/cfg-update

and simply follow the installation instructions again.

----------

## pross

works now  :Very Happy: 

----------

## whiskeypriest

Found this just in time for the XFree 4.3.0-r4 update...for those of us who didn't learn diff when we were being raised in the wild by bearded UNIX gurus, this is extraordinarily useful.

Nice application: installation and implementation were flawless.  Thanks.

----------

## infamousmrsatan

Hmm.. maybe I didn't follow the steps right, but my cfg-update still doesn't detect any config files that need updating (and etc-update does).

I'm guessing that I didn't update it right?

I re-downloaded the ebuild and followed all the instructions (including deleting the contents of /usr/local/portage/..... first).  I got the ebuild from the link on the first page of this post.

Is there something I'm doing wrong?  I really want to use cfg-update.

Thanks in advance,

Justin

----------

## pross

did u delete the file from /usr/portage/distfiles too?

----------

## infamousmrsatan

hmm.. maybe not. let me try that.

----------

## infamousmrsatan

Wait, there shouldn't be any /usr/portage distfiles should there? because the portage overlay is set, it looks in /usr/local/portage/app-portage/cfg-update.

I deleted the contents of that folder, and re-downloaded the ebuild from this forum, and that should take care of things, right?  Do I have to unmerge first, and THEN get the new ebuild??

----------

## pross

regardless of whether you are using overlay or not...the source is downloaded to /usr/portage/distfiles/ take a look for yourself...

----------

## infamousmrsatan

Ok, you were right.  I didn't realize where the tarballs were stored.  Thanks!

Now cfg-update recognizes the 128 or so files that need updating, but I get another problem...  when I type 'y' indicating that I would like to update a particular file, cfg-update doesn't open xxdiff.  Here's the output I get:

```

enigma justin # cfg-update -u

(1/123)  /etc/ssl/misc/CA.pl  [modified]

Update file : /etc/ssl/misc/CA.pl ? [y|n|q|?] y

 (GUI tool) : when done, use the save button with the M on it !

 (GUI tool) : you have not saved your selections as /etc/ssl/misc/CA.pl.merge !

Update cancelled...

(2/123)  /etc/ssl/openssl.cnf  [modified]

Update file : /etc/ssl/openssl.cnf ? [y|n|q|?] q

```

Any ideas (I will look around on the forums elsewhere too)

Man this has install has had so many pitfalls....

EDIT: SOLUTION

Turns out that it was one of the problems mentioned in the first troubleshooting section, about not being able to connect to x-server.  It wasn't giving me any error that indicated that, but when I tried using xxdiff independently of cfg-update, the error became aparent.  Whew!!

Thanks everyone for your help.

Justin  :Wink: 

----------

## yuza

I've just discovered a little problem with etc-update. Since it sets an alias for emerge in /etc/profile, you won't be able to set enviromental variables for portage anymore.

Things like

USE="something" emerge or

ACCEPT_KEYWORDS="~x86"

won't work anymore (at least with cfg-update-1.5)

----------

## xentric

 *yuza wrote:*   

> I've just discovered a little problem with etc-update. Since it sets an alias
> 
> for emerge in /etc/profile, you won't be able to set enviromental variables
> 
> for portage anymore.
> ...

 

I have never noticed that... Thanks for telling me this!

You can temporarily switch off the alias by typing:

```
cfg-update --off

source /etc/profile
```

Then do your emerge with USE flags, and restore the alias afterwards with:

```
cfg-update --on

source /etc/profile
```

----------

## yuza

Thanks for the trick!

----------

## micron

It's really a great job xentric, you've saved me!  :Very Happy: 

My etc-config segfaulted and I wasn't able to update my conf files, but now...  :Wink: 

Thanks a lot!

----------

## infamousmrsatan

Right!  I don't know if I ever said this, but now that I got it working, I am very very happy with cfg-update.  Updated those 120 or so config files in what seemed like no time at all.  :Very Happy: 

So as for turning the /etc/profiles thing --on and --off... when should you have to do this? Only when you want to declare an ACCEPT_KEYWORDS= or a USE= on the command line during an emerge??  Could it have an effect on anything else??

JS

----------

## yuza

Yes the problem is only when yuo are trying to set variables on the command line. I don't think it could have side effects on anything else.... xentric would have said that!

----------

## xentric

 *yuza wrote:*   

> Yes the problem is only when you are trying to set variables on the command line. I don't think it could have side effects on anything else...

 

Yes, the problem lies in the use of the alias. It doesn't handle variables

infront of a command. I have not yet encountered any other side-effects

and I don't expect them either.

I really want to thank you guys for the suggestions, support and bugreports!

I'm glad the script does what it was intended to do, making configuration

updates easy...

I do not have lot's of spare time, but I will keep fixing the bugs as soon as

you guys report them and I really hope that the script finally ends up in the

portage tree because updating the "updating-tool" is a pain right now.

----------

## yuza

 *Quote:*   

> 
> 
> I really hope that the script finally ends up in the portage tree
> 
> 

 

I'll keep my finger crossed!!  :Wink: 

----------

## chutz

I decided to try cfg-update 1.6 for the first time, and it is incredibly slow when it tried to create the index for the first time. It seems the problem is that grep is too slow. I adjusted the code like this:

```
--- cfg-update.pl   2004-02-13 02:20:47.000000000 +0900

+++ /usr/bin/cfg-update 2004-02-22 20:01:31.337632101 +0900

@@ -239,7 +239,7 @@

 }

 sub build_big{

-    `cat /var/db/pkg/*/*/CONTENTS | grep '^obj ' | awk '{ print \$2"  "\$3 }' >>$index`;

+    `cat /var/db/pkg/*/*/CONTENTS | awk '/^obj / { print \$2"  "\$3 }' >>$index`;

 }

 sub build_small{
```

and here is the result.

Patched version:

```
# date; cfg-update --index; date

Sun Feb 22 19:54:57 JST 2004

Use of uninitialized value in pattern match (m//) at /usr/bin/cfg-update line 271.

----------

## chutz

Another whine. This ebuild is now spending quality time on  "Converting old backups to new filename format....". No issues with that, but it is now searching my NFS mounted file systems that have a LOT of files... and it is of course not very fast. Not a very good impression for a first-time install.

----------

## xentric

I have changed the ebuild and conversion to the new format has to be done

manually now with the script provided in the ebuild... This way new installs and

already converted installs won't waste "quality time"  :Smile: 

```
root@xentric 56C xentric $ time cfg-update --index

----------

## St_Andrew

thanks a lot for this script man, has helped me a lot  :Smile: 

----------

## rudyfink

This is what I was looking for.

I'm very suprised the default merge tool doesn't have the graphical option as it's "merge interactively" section.

----------

## BlindSpy

AWESOME program!

----------

## yngwin

Just a note: textutils is now part of coreutils, you should update the ebuild!

----------

## xentric

 *yngwin wrote:*   

> Just a note: textutils is now part of coreutils, you should update the ebuild!

  Thanks for reporting this. I have updated the ebuild but I have no way

of testing it because my Gentoo system died after loosing the /var partition.

Can someone please test if the new ebuild works without problems?

(see first post, the link to the ebuild points to the updated version)

----------

## ndbruin

After I installed cfg-update I get the following error messages after starting cfg-update -u:

Use of uninitialized value in substitution (s///) at /usr/bin/cfg-update line 191.

Use of uninitialized value in pattern match (m//) at /usr/bin/cfg-update line 192.

The program works, but I am not sure if it will work properly.

----------

## xentric

 *ndbruin wrote:*   

> The program works, but I am not sure if it will work properly.

 

The warnings just show that a (s///) replace and a (m//) match are done

on an empty variable. If we take a look at lines 191 and 192:

```
190    $_ = $ENV{'CONFIG_PROTECT'};

191    s/\"//g;                                                               # strip " chars

192    until ($_ =~ /^$/) {
```

We can see that the environmental variable CONFIG_PROTECT is empty.

You can verify this with the 'env' command on the commandline.

As I recall correctly this value is set in /etc/make.globals, just check with

the following command:

```
root@gentoo 45C xentric $ grep -H "CONFIG_PROTECT" /etc/*

/etc/csh.env:setenv CONFIG_PROTECT '/usr/X11R6/lib/X11/xkb

 /usr/kde/3.3/share/config /usr/kde/3.3/env /usr/kde/3.3/shutdown

 /usr/share/config'

/etc/csh.env:setenv CONFIG_PROTECT_MASK '/etc/terminfo'

/etc/make.globals:CONFIG_PROTECT="/etc /var/qmail/control

 /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config"

/etc/make.globals:CONFIG_PROTECT_MASK="/etc/gconf"

/etc/profile.env:export CONFIG_PROTECT='/usr/X11R6/lib/X11/xkb

 /usr/kde/3.3/share/config /usr/kde/3.3/env /usr/kde/3.3/shutdown

 /usr/share/config'

/etc/profile.env:export CONFIG_PROTECT_MASK='/etc/terminfo'

```

As you can see the CONFIG_PROTECT variable is actually set in 3 different

locations on my system... 

/etc/csh.env

/etc/make.globals

/etc/profile.env

Maybe your system is missing some of these files!? cfg-update will work

correctly but if that variable isn't set anywhere it probably means that

portage has no protected directories and instead of making a ._cfg0000_

file it will just overwrite the original file without a warning...

So that's a bad thing !

The CONFIG_PROTECT variable on my system looks like this:

```
root@gentoo 43C xentric $ env | grep "CONFIG_PROTECT"

CONFIG_PROTECT_MASK=/etc/terminfo

CONFIG_PROTECT=/usr/X11R6/lib/X11/xkb /usr/kde/3.3/share/config /usr/kde/3.3/env /usr/kde/3.3/shutdown /usr/share/config
```

Maybe you can fix things with the above info...

----------

## gentsquash

When cfg-update is finally in portage, will its full name be

```
sys-apps/cfg-update
```

or will it be part of "sys-apps/portage", as "etc-update" is

currently?  

And when will it be `emerge'able?

----------

## xentric

I have no idea if it will be accepted as I don't get replies on my

mails from the devs... This is the way gentoo bugzilla works:

 *Quote:*   

> Granted, plenty of ebuilds sit in there and never make it into the tree.
> 
> This is not the fault of bugzilla, however.  It is more a problem with our
> 
> process.  Ebuilds make it into the tree when a developer cares about them.
> ...

 

You can check the status of this package here (or possibly

post a comment that you want it in the portage tree, maybe

that helps?):

https://bugs.gentoo.org/show_bug.cgi?id=32728

----------

## zebrapad

The script could add some option to copy the new file... example:

 *Quote:*   

> Update file : /etc/init.d/portmap ? [y|n|q|?] ?
> 
>   [y]es       merge the new and current config file in xxdiff
> 
>   [n]o        skip this file and go to the next config file
> ...

 

change to:

 *Quote:*   

> (2/71)  /etc/init.d/portmap  [no index]
> 
> Update file : /etc/init.d/portmap ? [y|n|c|a|q|?] ?
> 
>   [y]es       merge the new and current config file in xxdiff
> ...

 

plus,

if the user has created a .merge file ... do not ask for confirmation to use that merged file. Speaking for myself, I was sure when I saved it in xxdiff  :Smile: 

----------

## xentric

 *zebrapad wrote:*   

> The script could add some option to copy the new file... 

 

Well, these are your options:

```
  [y]es       merge the new and current config file in xxdiff

  [n]o        skip this file and go to the next config file

  [o]verwrite   <--------------- THIS IS WHAT YOU WANT !?

  [q]uit      quit immediately
```

But there are two situations that can disable the [o]verwrite option.

1. If cfg-update is installed while ._cfg0000_files are present on your

system, the first update session cannot use the automerge/overwrite

functionality! Cfg-update can't make a checksum index until all the

._cfg0000_files are updated manually... after it has created the checksum

index, cfg-update can automerge of if automerge is disabled if will show

the [o]verwrite option.

2. Unless, that configuration file has been edited by you. In this case 

cfg-update disables the [o]verwrite function and forces you to update

the file with xxdiff. (this is what makes cfg-update so safe!)

 *Quote:*   

> plus, if the user has created a .merge file ... do not ask for confirmation to use that merged file. Speaking for myself, I was sure when I saved it in xxdiff 

 Well, if you have saved the merged result as .merge you still

have to replace the current config file with the .merge file, otherwise it

still isn't updated!

If you accept the .merge file, cfg-update will backup the current config

file before it overwrites it with the .merge file...

----------

## xentric

Version 1.7 released...

Please test it and report any bugs in this thread: Troubleshooting cfg-update...

It can use meld now   :Very Happy: 

----------

## xentric

I have fixed a typo in the ebuild...

Users who have installed cfg-update v1.7 before this post date/time should

manually edit "/usr/local/portage/app-portage/cfg-update-1.7.ebuild"

Just change line 18:

```
gnome? ( >=dev-util-meld-0.9 )"
```

to:

```
gnome? ( >=dev-util/meld-0.9 )"
```

Otherwise you can encounter this error:

emerge: there are no ebuilds to satisfy ">=dev-util-meld-0.9".

```
root@kbl-vlis3383 852MHz 59C / $ emerge -uDp world

These are the packages that I would merge, in order:

Calculating world dependencies \

emerge: there are no ebuilds to satisfy ">=dev-util-meld-0.9".

!!! Problem with ebuild app-portage/cfg-update-1.7

!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.
```

----------

## ccduffy

I'm something of a fan of diff3-style merging (such that, instead of just merging 2 files together, a common ancestor is available to figure out which diff sections can be applied without human intervention and which require real human intervention) -- this should make it vastly easier to avoid presenting the user with updates to config files that they never touched/don't care about in the first place, and is IMNSHO the way that etc-update itself should have been written.

The etc-update replacement etc-update.rb (at http://www.wingding.demon.nl/etc-update.rb)  does exactly this -- but lacks the other functionality and slickness of cfg-update (and, for whatever reason, doesn't see all pending updates). Any chance of some future cfg-update release adding diff3 functionality?

Roughly, this would mean keeping a full copy of the ancestor around (rather than just its md5sum) and using this file for merges. Both xxdiff and meld support 3-way merging (and though meld lacks diff3-style automerge support, it's on the TODO).

----------

## xentric

 *ccduffy wrote:*   

> I'm something of a fan of diff3-style merging (such that, instead of just merging 2 files together, a common ancestor is available to figure out which diff sections can be applied without human intervention and which require real human intervention)

 

I'm already implementing this in the next version... still have some testing to

do. kdiff3 can do this sort of diffing and merging and cfg-update already makes

backups of the files it updates, so keeping another (anchestor) copy shouldn't be

too much of a problem to implement.

----------

## xentric

I can't get a usable result with 3-way diffing/merging and I'm starting to believe

that it's not really usable for automatic updating of configuration files due to the

nature of the whole 3-way diffing thing... I conclude that 3-way diffing was designed

to merge differences, not similarities... Please correct me if I'm wrong!

Here's an example to illustrate the logic behind the 3-way diff:

Two developers are both editing the sourcecode of program v1.0 and after a long

day of fixing bugs and implementing new stuff they decide to combine their work

into a new version v2.0! So one of the developers simply does a 3-way diff/merge

"$diff3 MY_VERSION OLD_VERSION YOUR_VERSION --output NEW_VERSION"

This works for them because differing or new lines are added to the new version

of the program.

But merging configuration files needs a different 3-way diff. We need the similarities

not the differences! So here's what happends:

/etc/example.ancestor (This is the base- or ancestor-file we kept around)

```
#header v1.0 - dec 2003

param1=customized_value

param2=customized_value

param3=default_value
```

/etc/example (This is the current configuration file)

```
#header v1.1 - aug 2004

param1=customized_value

param2=customized_value

param3=default_value
```

/etc/._cfg0000_example (This is the newest version available):

```
#header v1.2 - nov 2005

param1=default_value

param2=default_value

param3=default_value

param4=default_value
```

Here's what we need to successfully update our config file:

The ._cfg0000_ file has a new parameter (param4) and we want this to end

up in the merged output. But we also have customized values in the current

and ancestor file! So we want our customized values and the new parameter

all to end up in the output file, which will become our updated config file... 

Ok, let's try running kdiff3 (or any other 3-way diff tool) like this:

```
           MINE             YOURS                        ANCESTOR                   OUTPUT

kdiff3 /etc/example /etc/._cfg0000_example --base /etc/example.ancestor --output /etc/example.merged
```

/etc/example.merged (The automatically merged result)

```
<merge conflict - 3 different lines - you have to manually choose>

param1=default_value

param2=default_value

param3=default_value

param4=default_value
```

Even though both the current config file and the old ancestor config file have

customized parameters, the "differing" version is used in the merged output.

We don't get our customized values but we do get the new parameter line.

To be useful for auto-updating we need both so we can't use 3-way diff like this!

Ok, let's try to trick the 3-way diff by using the ._cfg0000_ file as ancestor:

```
           MINE                YOURS                    ANCESTOR                      OUTPUT

kdiff3 /etc/example.ancestor /etc/example --base /etc/._cfg0000_example --output /etc/example.merged
```

/etc/example.merged (The automatically merged result)

```
<merge conflict - 3 different lines - you have to manually choose>

param1=custom_value

param2=custom_value

param3=default_value

<no source line>
```

Cool, now we have our customized values in the merged output. But this time 

the new parameter isn't included automatically...

So, looking at these examples I think that 3-way diffing isn't very useful for

automatically merging configuration files. Well... at least it won't merge them

completely without user input. You'll be missing either your customized values

or newly included lines. You can't have both due to the fundamental design of 

the 3-way diff. Or am I overlooking something?  :Rolling Eyes: 

----------

## ccduffy

 *xentric wrote:*   

> So, looking at these examples I think that 3-way diffing isn't very useful for
> 
> automatically merging configuration files. Well... at least it won't merge them
> 
> completely without user input. You'll be missing either your customized values
> ...

 

Use the old original (non-modified) file as ancestor.

foo.conf.base:

```
#header v1.0

param1=default_value

param2=default_value

param3=default_value
```

foo.conf:

```
#header v1.0

param1=default_value

param2=modified_value

param3=modified_value
```

foo.conf.new:

```
#header v1.1

param1=default_value

param2=default_value

param3=default_value

param4=default_value
```

Unfortunetly, GNU diff3 still doesn't handle this quite right -- its behaviour is closer if there's space between the parameters such that they don't get chunked together (in which case it preserves the user's changes to param2 but not param3), but it's still not adequate. I'm playing with finding a solution -- but in the mean time, a simple reapplication of GNU Arch's update algorithm, with a little extra help from wiggle, presents itself:

```
diff -u3 foo.conf.base foo.conf.new > foo.conf.patch

patch foo.conf foo.conf.patch

wiggle foo.conf foo.conf.rej > foo.conf.updated
```

This is a slight bit dangerous, since wiggle tries hard to apply changes to the point of being willing to do risky things. Correspondingly, if patch outputs a reject file and it's necessary to call wiggle, this should be followed up by giving the user an opportunity to accept or reject wiggle's proposed resolution (using meld, xxdiff, whatever, to merge foo.conf with foo.conf.updated).

foo.conf.updated:

```
#header v1.1 - dec 2004

param1=default_value

param2=modified_value

param3=modified_value

param4=default_value
```

Volia!

The immediate impact of all this that the unmodified _cfg files should start being saved for posterity ASAP, since none of this goodness (either as above or diff3-based, if those wrinkles ever get ironed out) works without them.

----------

## xentric

Ahh... now I get it   :Very Happy: 

I need to use the previous ._cfg0000_foo as the ancestor, not the previous

/etc/foo ! I verified it and it works as it should... thanks for pointing me in the right direction !

----------

## cmuench

I did the digest instructions and it gave me this error

[code] ebuild /usr/local/portage/app-portage/cfg-update/cfg-update-1.7.ebuild digest

!!! aux_get(): ebuild path for 'app-portage/cfg-update-1.7' not specified:

!!!            None

!!! aux_get(): ebuild path for 'app-portage/cfg-update-1.7' not specified:

!!!            None

doebuild(): aux_get() error reading app-portage/cfg-update-1.7; aborting.

[/code]

----------

## xentric

 *cmuench wrote:*   

> I did the digest instructions and it gave me this error...

 

Check if /etc/make.conf has this line:

PORTDIR_OVERLAY="/usr/local/portage"

If you use another overlay directoy you have to change the digest command

to match your overlay directory.

----------

## cmuench

Okay i installed it okay and then when I typed in cfg-update -u it asked me about /etc/fstab I said overwrite without thinking. Know my /etc/fstab looks way different and I don't think its right.  Is there any way I can get my old fstab.  PLEASE HELP ME I don't want to reinstall my system.

----------

## radfoj

 *cmuench wrote:*   

> Okay i installed it okay and then when I typed in cfg-update -u it asked me about /etc/fstab I said overwrite without thinking. Know my /etc/fstab looks way different and I don't think its right.  Is there any way I can get my old fstab.  PLEASE HELP ME I don't want to reinstall my system.

 

I am also new to this script, but think, no problem. If you type "cfg-update" - it will show you options. You can see -b option, which list backup files and -r option will restore backup files.  But be patient. You must a little understand, what are you doing. Btw. this thread is not for such questions. See first post here by xentric.   Good luck.

----------

## ccduffy

So, I'll be honest: I'm impatient to see a diff3-enabled release.

Any word on when 1.8 will be done, other than "when it's ready"? How about public access to whatever revision control system you happen to use so that we can poke around / test your new version / break our systems with it?

----------

## xentric

 *ccduffy wrote:*   

> So, I'll be honest: I'm impatient to see a diff3-enabled release.

 

I'm not using CVS but I'd give you a snapshot to play with if I thought it would be remotely useful.

Right now the v1.8 script doesn't update correctly and the 3-way-merge is only half implemented.

So I won't let you mess up your system with it... yet.

Can't give you an acurate estimate on when it's ready for release, but I'll promise to make you the

first official beta-tester of cfg-update when basic functionality is restored and 3-way-merging is

properly implemented   :Very Happy:   OK !?

----------

## xentric

wrong button... oops

----------

## Freejack00

Nice program and idea, would be nice to have a link to the program.

----------

## xentric

 *Freejack00 wrote:*   

>  would be nice to have a link to the program.

 

I'm afraid I don't understand what you want... if you want it in portage, just

hold your breath as I guess it won't take long before it will be accepted!

I'm currently testing the last fixes in version 1.7.1 and when it's done

it will hopefully be added to the main portage tree very soon!

I will not rush to release version 1.8.0 but it won't take long before

that version is ready for release. Implementing of 3-way merging is almost

done and there are only a few functional modifications I still have to do...

Considering the time I have at the moment, I guesstimate version 1.7.1

to be ready by this weekend, and version 1.8.0 in about 4 weeks...

----------

## infamousmrsatan

w00t!

I just noticed that cfg-update is in portage now!  Anyway, I was wondering if there's any housekeeping I have to do if I have the old stuff installed in /usr/local/portage, etc.  Is there anything I should/have to do, or just emerge the ebuild?

If this is mentioned elsewhere, feel free to just direct me.

Thanks in advanced!

jms

----------

## xentric

I removed my overlay ebuild with "emerge -C cfg-update" and then

removed the /usr/local/app-portage/cfg-update directory...

Then I proceeded with a normal "emerge cfg-update". It will re-use

the checksum-index and shouldn't have any problems whatsoever.

Just follow the installation steps in the first post of this thread  :Smile: 

----------

## [UK]Superdude

Just thought I would quickly say how impressed I am with this tool.

I think the idea of indexing config files and recoording which ones are unmodified

is an innovation that really should be in portage by default.

Just a small thing that may imrpove it would be to set the alias in roots

.bash_profile (Ideally it would check to see what shell people are using

and update the correct profile). The main reason I say this is for the people

(like me  :Smile: ) who use emerge -ps as a normal user for the searching of portage

and have no need to run cfg-update.

Was there any reason against doing it this way? I do realise that /etc/profile is convenient, but

I dont think it really needs to be a system wide alias, having it as root should be enough, shouldn't it?

In any case, good work, makes gentoo even more powerful than it was before

----------

## xentric

 *[UK]Superdude wrote:*   

> Just a small thing that may imrpove it would be to set the alias in roots
> 
> .bash_profile (Ideally it would check to see what shell people are using
> 
> and update the correct profile). The main reason I say this is for the people
> ...

 

I have this issue on my todo list for the 1.8 version. I guess your suggestion

to put the alias in /root/.bash_profile is probably the best solution...

I can't make the checksum-index world writable (for security reasons)

so users need to use emerge (for installing) with root privileges anyway

if they want cfg-update to update it's checksum-index.

An alias in /root/.bash_profile will be sufficient.

I'll test it and implement it... Thanks !

----------

## jsgaarde

I'm trying to run cfg-update, but:

First run

```
gentoo jsg # cfg-update --off

Portage Log not found...

Enable PORT_LOGDIR in /etc/make.conf

Recommended: PORT_LOGDIR=/var/log/portage

Make sure the directory exists!
```

Create log dir

```
gentoo jsg # mkdir /var/log/portage
```

Edited /etc/make.conf

```
gentoo jsg # cat /etc/make.conf

# These settings were set by the catalyst build script that automatically built this stage

# Please consult /etc/make.conf.example for a more detailed example

CFLAGS="-march=athlon-xp -pipe -O2"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

GENTOO_MIRRORS="http://mirror.uni-c.dk/gentoo http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo"

USE="-gtk -gnome qt kde dvd alsa cdr winbind live nas network divx4linux 3dnow nvidia mozilla sdl dvdr ffmpeg"

PORT_LOGDIR in /etc/make.conf
```

Second run

```
gentoo jsg # cfg-update --off

No (protected) directories found...
```

Now what should I do?

Best regards

Jakob Simon-Gaarde

----------

## mirko_3

```

mirko_3@mirko3 ~ $ cat /etc/make.conf|grep PORT_

PORT_LOGDIR=/var/log/portage

```

This, maybe?

----------

## xentric

Yeah, it must have this line:

```
PORT_LOGDIR=/var/log/portage
```

```
No (protected) directories found...
```

This worries me... it basically means that you never have to use

etc-update or cfg-update because you never get any ._cfg0000_ files

on your system as portage simply replaces your config files with

default files. You can imagine what happends if /etc/fstab get's 

overwritten. If you do a world update, your system may become

unbootable due to overwritten files...

If you really haven't got any protected directories you better

search the forums on how to fix this ASAP!

If you have fixed the above, you run "cfg-update --on" (only once)

to integrate cfg-update into every emerge action. You just turned it

off with the --off option. You can use cfg-update without emerge

integration, but then it can't tell you if files are modified or not...

that means manual merging for each and every ._cfg0000_ file.

For normal use you simply do "cfg-update -l" to see which files have

updates, followed by "cfg-update -u" to start the updating process.

It's as simple as that...

BTW, what gave you the impression that you should run "cfg-update --off"?

I really want to know if there are unclear instructions in the manpage,

install instructions on the forums, or in the usage output...

----------

## neerolyte

i rather like this, can we have this as the default now?

----------

## sfp-a7x

Rather than making the alias for emerge in /etc/profile, why not add a file in /etc/env.d and run env-update?

Is /etc/env.d is only for environment variables?

----------

## xentric

 *sfp-a7x wrote:*   

> Rather than making the alias for emerge in /etc/profile, why not add a file in /etc/env.d and run env-update?
> 
> Is /etc/env.d is only for environment variables?

 Well, I have never tried to set an alias from there...

----------

## wolfbite_aus

Am I missing something?

I would like to be able to do cfg-update -cfg and just make the _cfg file the new one automaticlly (usually if I've done a pile of emerge's.

Also

is it possable to get cfg-update to ignore a particular file?

say edit the first line

#cfg-update false

and cfg-update would just ignore (because your always playing with it? or you do a manual diff but its an added precaution)

Thanks for any help

----------

## xentric

 *wolfbite_aus wrote:*   

> I would like to be able to do cfg-update -cfg and just make the _cfg file the new one automaticlly (usually if I've done a pile of emerge's.

 If you do a "cfg-update -l" it'll show you which files have ._cfg0000_files and need to be updated. It will also show the status of these files (modified, unmodified, unknown, etc). The first priority of cfg-update is to let you safely update your system. This means that the status of a file has a direct effect on the way cfg-update handles that particular file. If a file has been changed after it was installed by portage, it probably means that you, a system process or a program have put settings in that file so cfg-update will never simply overwrite the current (modified) file with the ._cfg0000_file. It will force you to manually merge this file in the diff/merge tool of your choice!

If you have just installed cfg-update you will probably have to manually merge all files with the diff/merge tool. This is because cfg-update cannot determine the status of the files yet. You need a checksum-index before cfg-update can automatically determine which files can be updated safely by overwriting them with the ._cfg000)_file. This checksum-index will be automatically created as soon as you have updated all files manually first...

So on the second update session cfg-update can use this index and it will be able to speed up the updating proces significantly because it will take care of all the (unmodified) files that don't need your attention!

 *Quote:*   

> is it possable to get cfg-update to ignore a particular file?
> 
> say edit the first line
> 
> #cfg-update false
> ...

  If you have added such a line to the file cfg-update will see that it has changed and will ask you what to do with it. Just choose [n]o to skip this file and go to the next file... or choose [y]es and update it manually in the diff/merge tool. It will never overwrite a modified file with the ._cfg0000_file!

----------

## piavlo

it seems like the cfg-update is not respecting CONFIG_PROTECT_MASK

could it be fixed?

----------

## xentric

 *piavlo wrote:*   

> it seems like the cfg-update is not respecting CONFIG_PROTECT_MASK
> 
> could it be fixed?

 I will look into this... I'll keep you updated on the results.

----------

## NullDevice

Hey,

im new to cfg-update. Do i have to read all of the troubleshooting thread, like 100 posts.. or is there a simple users guide or howto to read?

Im scared to break my system, but i have 42 config file to be updated, according to portage.

----------

## NullDevice

ah, got it now, sryy i found it.

----------

## xentric

 *xentric wrote:*   

>  *piavlo wrote:*   it seems like the cfg-update is not respecting CONFIG_PROTECT_MASK
> 
> could it be fixed? I will look into this... I'll keep you updated on the results.

 Hmm... after some thinking I came to this conclusion:

Portage uses CONFIG_PROTECT and CONFIG_PROTECT_MASK to determine which directories to protect and which directories in the protected directories can be excluded from protection. As a result, you will not get any ._cfg0000_files in the directories in CONFIG_PROTECT_MASK because these directories are excluded from the protection mechanism and all config files in these unprotected directories are automatically overwritten, by Portage, with the new version of that file. 

So the fact that cfg-update doesn't exclude the directories in CONFIG_PROTECT_MASK while searching for ._cfg0000_files shouldn't matter as there shouldn't be any ._cfg0000_files in those directories anyway!

If cfg-update does find ._cfg0000_files in those dirs, you should start to wonder if Portage has a bug that causes it to ignore CONFIG_PROTECT_MASK.

----------

## rjmckee

Killer script! Thank you Xentric!

I had 26 files that needed updating and I was afraid after the last time I borked my system w/ etc-update.

Your script ran just fine.... no errors, system still runnung   :Smile: 

Regards and thanks again,

Ray

----------

## alaskazimm

Oh man, thanks for all the work on this script! I came across this a couple of weeks ago and  it is a *whole* lot easier than etc-update.

No problems on this end. I've used it to update numerous config files and it is sweet.

Thanks again

----------

## GeYe

I unmerge cfg-update and now this:

```
bash: emerge_with_indexing_for_cfg-update: command not found
```

when I try to emerge.

How to solve this now, because I can't emerge anything now.

----------

## leon_73

 *GeYe wrote:*   

> I unmerge cfg-update and now this:
> 
> ```
> bash: emerge_with_indexing_for_cfg-update: command not found
> ```
> ...

 

I'm not sure but try to see if you have some alias... and check the /etc/profiles file....

Leo

----------

## GeYe

Yes in the file /etc/profiles were these lines:

```
# cfg-update uses this alias to update it's checksum-index *before* emerging

alias emerge='emerge_with_indexing_for_cfg-update'
```

You need to delete the lines and run 

```
env-update 
```

and 

```
source /etc/profile
```

. 

Thanks for this hint. Maybe the unmerge-script need an update   :Wink: 

----------

## xentric

 *GeYe wrote:*   

> Thanks for this hint. Maybe the unmerge-script need an update  

 Actualy, the problem is that on updating a package, the new package is installed first, then the old package get's unmerged. So if I turn off the alias in the unmerge routine of the ebuild, the new script isn't using the alias anymore.

In the next version I have already implemented a check that warns if the alias is disabled and it explains how you can turn it on again. This will make it possible to turn off the alias during unmerging... I'll put that in the 1.8.0 ebuild.

----------

## Sheepdogj15

this is definitely nice. i've been using cfg-update for what, about a month now? i've noticed no problems, and defintely blows etc-update out of the water. i can rest knowing i won't have to redo my custom configs every time. 

BTW, a tip for adding it to the KDE menu. Open the KDE Menu Editor (kmenuedit, and i believe the ebuild is kde-base/kmenuedit if you don't have it). expand either System or Utilities, wherever you want to put it, and hit ctrl-N for a new item. fill in the name and the command (cfg-update -u). select the "Run in terminal" and "Run as a different user" checkboxes. you don't have to enter anything for the user, as it defaults to root. you may also want to give it an intuitive icon.

----------

## xentric

 *Sheepdogj15 wrote:*   

> BTW, a tip for adding it to the KDE menu....

 Thanks for the tip, I didn't even think about that!

I have added the tip to the cfg-update installation instructions.

----------

## Sheepdogj15

no problem, man  :Smile: 

----------

## wolfbite_aus

maybe I missed it, maybe it doesnt exist

What I would like is, on the first line of the config to have say 

#cfg_never

cfg_update would come up with a message saying 

## You have requested to never modify this ????.conf

## Leaving the current ????.alone

is this possable? or already implemented.

(mainly for those blasted files I accidently update (yes I know I have a backup, but sometimes you miss something till you need it  :Smile: 

and what about an -new flag

just update ALL conf with the newer one (BUT cfg_never still overides)

Great program otherwise  :Smile: )

----------

## xentric

 *wolfbite_aus wrote:*   

> ## You have requested to never modify this ????.conf
> 
> ## Leaving the current ????.alone

 Well, I chose a different approach. It's not a good idea to ignore updates! I've made cfg-update auto-update all files that haven't been touched by you after they were installed. That way, you don't have to spend time on those files, but they do get updated.

 *Quote:*   

> and what about an -new flag
> 
> just update ALL conf with the newer one (BUT cfg_never still overides)

 That option is exactly what get's so many people into trouble with etc-update! I chose to force people to look at those files which NEED to be looked at before they can be updated. I will never implement an "update-all-without-asking" option, however the next version will have an option that "updates-all-unmodified-files" and leaves the rest for later...

You probably haven't seen the auto-update in action yet... it becomes active after the first updating session, so on the first run you have to update every ._cfg0000_file manually but on the second session (after your next world update) you'll notice that cfg-update will update 90% of the files automatically.

The first design objective was to make updating with cfg-update SAFE, the second was to make it EASY.

----------

## wolfbite_aus

I dont ignore configs

the configs that affect me, I note.

The ones that dont i have to go through manually going y r y r y r r r r r r r r r y r (cli  :Smile: 

out of the configs, I either 

edit the ones manually (xorg.conf, make.conf)

and the ones I dont (pam, etc) just y r y r y r r r r r r r r r

so far this has worked (almost 12 months  :Smile: 

But some configs I KNOW that I SHOULDNT be touching.

what about #CFG_ALWAYS

cfg-update AUTOmaticly use the newer one (and adds #CFG_ALWAYS to the firstline)

atleast you have made the person manually go through and add the words 

then on THEIR heads.....  :Smile: 

But having the choice will help people with LOTs of updating configs

#CFG_NEVER             (this file will be updated by the user

#CFG_ALWAYS          (this file will ALWAYS use the newer conf

Your program has made me updated the configs MORE now than I used to  :Smile: 

----------

## xentric

 *wolfbite_aus wrote:*   

> I dont ignore configs

 Good   :Very Happy: 

 *Quote:*   

> the configs that affect me, I note.
> 
> The ones that dont i have to go through manually going y r y r y r r r r r r r r r y r (cli 

 Do you mean that you always have to manually merge files even though you haven't modified them at all? This sounds like cfg-update isn't working properly.

If cfg-update is installed properly, it should use the alias for the emerge command in /etc/profile which causes "cfg-update --index" to run before every emerge action. See this example:

```
root@gentoo 852MHz 64C xentric # emerge -uDpv world

----------

## wolfbite_aus

wolfden wolfbite # emerge -uDpv world

These are the packages that I would merge, in order:

Calculating world dependencies ...done!

[blocks B     ] <=net-wireless/ipw2100-1.1.0 (is blocking net-wireless/ieee80211-1.0.3)

[blocks B     ] =kde-base/kappfinder-3.4* (is blocking kde-base/kdebase-3.4.1-r1)

[blocks B     ] =kde-base/kcheckpass-3.4* (is blocking kde-base/kdebase-3.4.1-r1)

[blocks B     ] =kde-base/kmenuedit-3.4* (is blocking kde-base/kdebase-3.4.1-r1)

etc etc

>>cfg-update message about the checksum index everytime you use the emerge command.

no, never.

checked cfg-update (1.7.2)

(guess I better update that too  :Smile: 

yes I have to hand check (although cfg-update updates the ones that havent change)

but if one little thing is different, then throws up diff and it gets me to select l/r

guess I must still be missing something

it keeps mussing my configs that I DONT want changed  :Sad: 

I am getting more vigilent, but can still miss some (bloddy wife talking  :Smile:  hahaha etc

will emerge the latest and see if I can get it rolling better

Thanks for the feedback atleast  :Smile: )

----------

## wolfbite_aus

you show 

root@gentoo 852MHz 64C xentric # emerge -uDpv world

----------

## xentric

 *wolfbite_aus wrote:*   

> so if I
> 
> cfg-update --fix
> 
> source /etc/profile
> ...

 

1.7.2 is the latest. Cfg-update 1.8.0 is not in portage yet, I'm testing it but it's not yet ready for release.

Just follow the installation instructions to make it work like it's supposed to  :Smile: 

It shouldn't matter if the new ._cfg0000_file has changed slightly compared to the original config file. Only if you have changed the original config file, after it was installed, cfg-update should force you to update manually. If you haven't put settings in a file, it should auto-update...

----------

## blank_vlad

 *xentric wrote:*   

> Cfg-update 1.8.0 is not in portage yet, I'm testing it but it's not yet ready for release.

 

What's the status on 1.8.0? Do you need help testing?

----------

## xentric

I'm trying really hard to get 1.8.0 ready before the end of this year... 

I didn't have to work (vacation) this week for the first time since february and I wanted to implement automatic 3-way merging with merge-conflict detection. The code got a bit messy so I decided to completely rewrite the update routine and split the updating process up in 5 different stages. These stages  can be independently enabled/disabed to suit your needs. As soon as it's ready for testing I will post it here so you can test it!

Some new features:

```
- Updating in stages:

     stage1 -  Automatic overwriting           (unmodified files, unmodified binaries)

     stage2 -  Automatic 3-way merging         (modified files, custom files)

     stage3 -  Manual 3-file merging           (modified files, custom files)

     stage4 -  Manual 2-file merging           (modified files, custom files)

     stage5 -  Manual replacing of other files (modified binaries, custom binaries, link-to-file, file-to-link, link-to-link)

- Fixed unnecessary checksum-index updates.

- Uses a configuration file for settings (/etc/cfg-update.conf)

- Added new options:

     -a, --automatic

                   Only does automatic updates and skips stage 3,4,5 (for use with cronjob)

     -p, --pretend

                   Pretend update

     -t, --tool

                   Set a merge tool on the commandline (overrides default setting in /etc/cfg-update.conf)

```

----------

## travlr

 *xentric wrote:*   

> I'm trying really hard to get 1.8.0 ready before the end of this year...

 

xentric, 

Just wanted to throw out a big thanks :^) 

cfg-update is a huge help and we  very much appreciate your contributions...

travlr

----------

## Devport

IMHO cfg-update really should become the gentoo default. I use it for a year now and it works like a charm. Why maintain old dumb etc-update when there is cfg-update which is much more useful on X / GNOME / KDE based systems and still as good on console only systems...

----------

## blank_vlad

Excellent, the new cfg-update ebuild is in bugzilla and ready for testing: https://forums.gentoo.org/viewtopic-t-86622.html

While waiting for the new version, I rigged dispatch-conf to use Meld just to see if it would work, and it does. All I had to do was edit /etc/dispatch-conf.conf, comment out two existing lines and replace them:

```
#diff="colordiff -Nu %s %s | less --no-init --QUIT-AT-EOF"

diff="meld %s %s"

#merge="sdiff --suppress-common-lines --output=%s %s %s"

merge="echo %s > /dev/null && meld %s %s"

```

That last line is kind of a kludge because Meld will only take 2 parameters on the command line for a 2-way comparison and dispatch-conf wants to send it 3 parameters, so instead of modifying dispatch-conf's code I just made the shell chomp the extra parameter with some ugly command line fu.

Now what I'm wondering is, other than user interface improvements, what advantages do we get with cfg-update's handling of config files over dispatch-conf's?

----------

## xentric

 *blank_vlad wrote:*   

> Now what I'm wondering is, other than user interface improvements, what advantages do we get with cfg-update's handling of config files over dispatch-conf's?

 

Dispatch-conf and cfgupdate both do the same autoupdating of unmodified files.

Dispatch-conf can autoupdate CVS and cruft changes, cfg-update does fully automatic

3-way merges if it's possible. It needs the backup of the previous ._cfg0000_ file for this

so it means that the longer you use cfg-update, the better it get's.

I will check if I can get these original files from the tarball of the package for all modified

files, so we can always let cfg-update try an automatic 3-way merge on modified files.

With cfg-update you can easily change between xxdiff, kdiff3, meld, tkdiff, kompare, gtkdiff

and sdiff. They all have been configured and tested and the script gives you info on how to

save the merged result when you are done, depending on the tool you are using.

You can use cfg-update with automated system maintenace scripts and cronjobs

because the -a option only does the automatic updates and skips all manual updates...

But dispatch-conf is good too, so just use whatever you like best!

----------

## ping-uino

I tried your cfg-update program on my sparc...

And everythings seems work well...

Then, why not include sparc as testing architecture?  :Wink: 

I'm using the "old" 1.7.1 and i emerged few packages, but the difference between etc-update is evident!

Very good work, congratulation!

----------

## xentric

 *ping-uino wrote:*   

> I tried your cfg-update program on my sparc...
> 
> And everythings seems work well...
> 
> Then, why not include sparc as testing architecture? 
> ...

 

Thanks for your feedback  :Very Happy: 

If 1.7.1 works on sparc, then 1.8.0 should also work on sparc!

I'll ask the package maintainer to include ~sparc.

----------

## ping-uino

 *Quote:*   

> I'll ask the package maintainer to include ~sparc.

 

It would be great!

And i'm impatience to see this tool instead etc-update!

(and trying it on every architecture is one step)

I upgraded to the last 1.8.0-r3 version, emerged without problem...

Then i'm updating many packages for testing, but at this moment i haven't any problem...    :Very Happy: 

I'd like to see a simple website page for cfg-update, forum is not very functional to search packages  :Smile: 

Okay, the last complain (i promised!)

for the "manual" in my (humble) opinion:

> Enable the alias for emerge in /root/.bash_profile:

I'd write something like: "enable cfg-update on your system"

The first time i read it (i'm not english, i know my english is poor...) i believed to add manaully an alias to my .bashrc!

> Log out and use sux to become root again

I'm console purist... Can you put this step optional?!  :Smile: 

And why not put in some part a very little guide about common commands?

Something like:

To list update: cfg-update -xyz

Bye!

----------

## xentric

 *ping-uino wrote:*   

> And i'm impatience to see this tool instead etc-update!

 Well, I think that cfg-update will never become the default tool because it's written in perl. If I had written it in python or bash it would have had a much better chance of becoming the default tool. 

 *Quote:*   

> (and trying it on every architecture is one step)

 I've found someone willing to test cfg-update on a Mac too. So I'll wait for the results and hopefully I can email the package maintainer soon to have him add ~ppc and ~sparc as supported systems  :Very Happy: 

 *Quote:*   

> I'd like to see a simple website page for cfg-update, forum is not very functional to search packages 

 Right now I have redirected the url which is mentioned in the ebuild, manpage and on packages.gentoo.org to this forum post. I can make a simple page and remove the redirection... but to be honest, this has a very low priority on my tasklist.

 *Quote:*   

> Okay, the last complain (i promised!)

 I don't see this as complaints but as constructive criticism. Your suggestions, tips, ideas, dislikes and complaints are all equally welcome!

 *Quote:*   

> for the "manual" in my (humble) opinion:
> 
> > Enable the alias for emerge in /root/.bash_profile:
> 
> I'd write something like: "enable cfg-update on your system"
> ...

 Good point... I will update the instructions.

 *Quote:*   

> > Log out and use sux to become root again
> 
> I'm console purist... Can you put this step optional?

 I can, and it is actually optional... but because the root account on Gentoo systems is configured very restricted by default, and most people use an Xserver, I think this is a sane instruction for most installs. But I will add a note for CLI-only freaks  :Wink: 

I'll change the 1.8.0-r4 ebuild so that sux is not a dependency when USE="-kde -gnome"!

 *Quote:*   

> And why not put in some part a very little guide about common commands?
> 
> Something like:
> 
> To list update: cfg-update -xyz

 I figured that the manpage is a good place to put this in. Just type "man cfg-update" and scroll down to the EXAMPLES section to see some basic usage examples.

----------

## Rick

Just wondering, would it be possible to use colordiff/vimdiff instead of sdiff, the tiny b/w sdiff window isn't very pleasant to look at. And as you can understand I don't have X running on my servers  :Rolling Eyes: 

----------

## xentric

 *Rick wrote:*   

> Just wondering, would it be possible to use colordiff/vimdiff instead of sdiff, the tiny b/w sdiff window isn't very pleasant to look at.

 I'm not familiar with vimdiff, but you can try "cfg-update -u -t vimdiff" or "cfg-update -u -t /TYPE_PATH_HERE/vimdiff". If that works, you can change the default tool setting in /etc/cfg-update.conf

----------

## Rick

Well, that's what I've tried but it won't cooperate :X

```
# cfg-update -mu -t /usr/bin/colordiff

<< Stage1 >> disabled with -m or --manual flag, skipping...

<< Stage2 >> disabled with -m or --manual flag, skipping...

* GUI not available, unable to run the mergetool set in /etc/cfg-update.conf

* you can only use a cmdline tool like "sdiff" for interactive/manual merging!

* Run cfg-update from within an X-terminal to use the GUI tool for merging

* or if you use this script on a system without an X-server you can change the

* MERGETOOL to /usr/bin/sdiff in /etc/cfg-update.conf or by using the -t option

* like: "cfg-update -u -t /usr/bin/sdiff"
```

Here's my current config (without the comments)

```
MERGETOOL = /usr/bin/sdiff

ENABLE_BACKUPS = yes

ENABLE_STAGE1 = yes

ENABLE_STAGE2 = yes

ENABLE_STAGE3 = no

ENABLE_STAGE4 = yes

ENABLE_STAGE5 = yes
```

Edit after looking at the code I found the problem, fixed it by removing the $mergetool check since it's kind of silly to force a few specific tools if a gui isn't available  :Razz: 

----------

## xentric

 *Rick wrote:*   

> Edit after looking at the code I found the problem, fixed it by removing the $mergetool check since it's kind of silly to force a few specific tools if a gui isn't available 

 I'll test and fix that mergetool check in the next version. Thanks for telling me this!

----------

## Rick

A good fix would probably be to give a warning if the user tries xxdiff/kdiff3/meld at the console, right now I've just removed the entire check but that will be confusing for people that don't have the settings right.

----------

## Kasumi_Ninja

Wow nice tool. Might be just what I am looking for! Emerging it now   :Smile: 

Edit:  it works just fine. Though I would like some additional  information about using xxdiff. If I get that screen in front of mee I don't have a clue about what to do next. Now I check the diffrences between the left and the rightpane. and decide whicgh which one l like ro keep.

----------

## Kasumi_Ninja

Another problem I encountered is the 'high requirements' of cfg-update. When trying to install on a newly installed system with fluxbox running I get this longs list:

```
emerge -av cfg-update

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] app-text/aspell-0.50.5-r4  USE="gpm" 992 kB 

[ebuild  N    ] media-libs/libmad-0.15.1b  USE="-debug" 490 kB 

[ebuild  N    ] media-libs/lcms-1.14-r1  USE="jpeg python tiff zlib" 653 kB 

[ebuild  N    ] media-libs/libmng-1.0.8-r1  497 kB 

[ebuild  N    ] app-text/poppler-0.5.3  USE="jpeg" 1,025 kB 

[ebuild  N    ] net-print/cups-1.1.23-r8  USE="nls pam ssl -gnutls -samba -slp" 

8,501 kB 

[ebuild  N    ] x11-libs/qt-3.3.6-r1  USE="cups gif ipv6 opengl xinerama -debug 

-doc -examples -firebird -immqt -immqt-bc -mysql -nas -nis -odbc -postgres -sqli

te" 14,224 kB 

[ebuild  NS   ] dev-libs/glib-2.10.3  USE="-debug -doc -hardened" 2,708 kB 

[ebuild  N    ] media-libs/libogg-1.1.2  410 kB 

[ebuild  N    ] kde-base/kde-env-3-r4  0 kB 

[ebuild  N    ] media-libs/libvorbis-1.1.0  USE="-aotuv" 1,281 kB 

[ebuild  N    ] media-libs/audiofile-0.2.6-r1  365 kB 

[ebuild  N    ] media-sound/esound-0.2.36-r1  USE="alsa ipv6 tcpd -debug -static

" 361 kB 

[ebuild  N    ] kde-base/arts-3.5.2-r1  USE="alsa esd mp3 vorbis xinerama -artsw

rappersuid -debug -jack -kdeenablefinal -kdehiddenvisibility -nas" 944 kB 

[ebuild  N    ] dev-libs/libxml2-2.6.26  USE="ipv6 python readline -debug -doc -

test" 3,338 kB 

[ebuild  N    ] dev-libs/libgpg-error-1.0-r1  USE="nls" 316 kB 

[ebuild  N    ] dev-libs/libgcrypt-1.2.2-r1  USE="nls" 939 kB 

[ebuild  N    ] dev-libs/libxslt-1.1.17  USE="crypt python -debug" 1,865 kB 

[ebuild  N    ] dev-libs/libpcre-6.3  USE="-doc" 552 kB 

[ebuild  N    ] net-dns/libidn-0.5.15  USE="java nls -doc -emacs" 1,925 kB 

[ebuild  N    ] media-libs/libart_lgpl-2.3.17  USE="-debug" 282 kB 

[ebuild  N    ] x11-libs/cairo-1.0.4  USE="X png -doc -glitz" 1,441 kB 

[ebuild  N    ] x11-libs/pango-1.12.3  USE="-debug -doc" 1,197 kB 

[ebuild  N    ] dev-libs/atk-1.11.4  USE="-debug -doc" 606 kB 

[ebuild  N    ] x11-misc/shared-mime-info-0.16  735 kB 

[ebuild  NS   ] x11-libs/gtk+-2.8.19  USE="X jpeg tiff xinerama -debug -doc" 12,

015 kB 

[ebuild  N    ] media-fonts/gnu-gs-fonts-std-8.11  3,664 kB 

[ebuild  N    ] app-text/ghostscript-gpl-8.54  USE="X cups gtk -cjk -emacs -jpeg

2k" 12,082 kB 

[ebuild  N    ] virtual/ghostscript-0  0 kB 

[ebuild  N    ] app-dicts/aspell-en-0.51.1  168 kB 

[ebuild  N    ] app-admin/gamin-0.1.7  USE="-debug -doc" 529 kB 

[ebuild  N    ] kde-base/kdelibs-3.5.2-r6  USE="alsa arts cups spell ssl tiff xi

nerama -acl -debug -doc -jpeg2k -kdeenablefinal -kdehiddenvisibility -kerberos -

legacyssl -openexr -zeroconf" 15,101 kB 

[ebuild  N    ] dev-util/tmake-1.8-r1  46 kB 

[ebuild  N    ] dev-util/xxdiff-3.0.2-r1  USE="kde" 1,039 kB 

[ebuild  N    ] dev-libs/libIDL-0.8.6  USE="-debug -static" 342 kB 

[ebuild  N    ] gnome-base/orbit-2.14.0  USE="ssl -debug -doc -static" 687 kB 

[ebuild  N    ] dev-python/pyorbit-2.14.0  USE="-debug" 269 kB 

[ebuild  N    ] gnome-base/libglade-2.5.1  USE="-debug -doc" 310 kB 

[ebuild  N    ] gnome-base/libbonobo-2.14.0  USE="-debug -doc" 1,354 kB 

[ebuild  N    ] gnome-base/gnome-mime-data-2.4.2  USE="-debug" 829 kB 

[ebuild  N    ] net-misc/neon-0.25.3  USE="ssl zlib -expat" 713 kB 

[ebuild  N    ] gnome-base/gconf-2.14.0  USE="-debug -doc" 1,851 kB 

[ebuild  N    ] sys-fs/device-mapper-1.02.07  902 kB 

[ebuild  N    ] sys-fs/cryptsetup-luks-1.0.3-r2  USE="nls -dynamic -pic" 297 kB 

[ebuild  N    ] dev-lang/swig-1.3.25  USE="java perl python -doc -guile -php -ru

by -tcl -tk" 3,370 kB 

[ebuild  N    ] sys-libs/libcap-1.10-r5  USE="python -nocxx -static" 38 kB 

[ebuild  N    ] dev-libs/libusb-0.1.10a  USE="-debug -doc" 366 kB 

[ebuild  N    ] dev-python/pyrex-0.9.3-r2  171 kB 

[ebuild  N    ] sys-apps/dbus-0.61-r1  USE="X gtk python qt3 -debug -doc -mono" 

1,695 kB 

[ebuild  N    ] gnome-base/gnome-vfs-2.14.2  USE="hal ipv6 ssl -avahi -debug -do

c -gnutls -samba" 1,773 kB 

[ebuild  N    ] gnome-base/libgnome-2.14.1  USE="esd -debug -doc -static" 971 kB

 

[ebuild  N    ] gnome-base/libgnomecanvas-2.14.0  USE="X -debug -doc -static" 59

7 kB 

[ebuild  N    ] gnome-base/libbonoboui-2.14.0  USE="X -debug -doc" 872 kB 

[ebuild  N    ] gnome-base/gnome-keyring-0.4.9  USE="-debug" 386 kB 

[ebuild  N    ] gnome-base/libgnomeui-2.14.1  USE="jpeg -debug -doc" 1,847 kB 

[ebuild  N    ] x11-themes/hicolor-icon-theme-0.8  30 kB 

[ebuild  N    ] dev-perl/XML-NamespaceSupport-1.09  USE="perl -minimal" 7 kB 

[ebuild  N    ] dev-perl/XML-SAX-0.13  USE="perl -minimal" 57 kB 

[ebuild  N    ] virtual/perl-Storable-2.15  0 kB 

[ebuild  N    ] dev-perl/XML-Simple-2.14  USE="perl -minimal" 64 kB 

[ebuild  N    ] x11-misc/icon-naming-utils-0.7.0  59 kB 

[ebuild  N    ] x11-themes/gnome-icon-theme-2.14.2  USE="-debug" 2,878 kB 

[ebuild  N    ] net-print/libgnomecups-0.2.0  USE="-debug" 303 kB 

[ebuild  N    ] gnome-base/libgnomeprint-2.12.1  USE="cups -debug -doc" 769 kB 

[ebuild  N    ] gnome-base/libgnomeprintui-2.12.1  USE="-debug -doc" 631 kB 

[ebuild  N    ] dev-python/pyopengl-2.0.0.44  1,251 kB 

[ebuild  N    ] dev-python/pycairo-1.0.2  USE="gtk -numeric -svg" 458 kB 

[ebuild  N    ] dev-python/numeric-23.7  708 kB 

[ebuild  N    ] x11-libs/gtkglarea-1.99.0  USE="-debug" 205 kB 

[ebuild  N    ] dev-python/pygtk-2.8.6  USE="opengl -doc" 739 kB 

[ebuild  N    ] dev-python/gnome-python-2.12.4  USE="-debug -doc -gtkhtml" 368 k

B 

[ebuild  N    ] app-text/sgml-common-0.6.3-r4  74 kB 

[ebuild  N    ] app-text/build-docbook-catalog-1.2  3 kB 

[ebuild  N    ] app-text/docbook-xsl-stylesheets-1.68.1-r1  944 kB 

[ebuild  N    ] app-arch/unzip-5.52  1,113 kB 

[ebuild  N    ] app-text/docbook-xml-dtd-4.1.2-r6  73 kB 

[ebuild  N    ] app-text/scrollkeeper-0.3.14-r2  USE="nls" 663 kB 

[ebuild  N    ] gnome-extra/libgda-1.2.2-r1  USE="berkdb -debug -doc -firebird -

freetds -ldap -mdb -mysql -oci8 -odbc -postgres -sqlite -xbase" 1,212 kB 

[ebuild  N    ] x11-apps/xdpyinfo-1.0.1  USE="-debug" 85 kB 

[ebuild  N    ] www-client/mozilla-launcher-1.49  5 kB 

[ebuild  N    ] dev-libs/nspr-4.6.1-r2  USE="ipv6" 1,301 kB 

[ebuild  N    ] app-arch/zip-2.31  USE="crypt" 783 kB 

[ebuild  N    ] dev-libs/nss-3.11-r1  4,885 kB 

[ebuild  N    ] www-client/mozilla-firefox-1.5.0.4  USE="gnome ipv6 java xineram

a -debug -mozdevelop -xprint" LINGUAS="-ar -ca -cs -da -de -el -en_GB -es -es_AR

 -es_ES -fi -fr -ga -ga_IE -he -hu -it -ja -ko -mk -nb -nb_NO -nl -pl -pt_BR -ro

 -ru -sk -sl -sv -sv_SE -tr -zh_CN -zh_TW" 34,550 kB 

[ebuild  N    ] gnome-extra/gtkhtml-2.6.3  USE="-accessibility -debug" 382 kB 

[ebuild  N    ] app-text/enchant-1.2.5  519 kB 

[ebuild  N    ] app-text/gtkspell-2.0.11-r1  USE="-doc" 339 kB 

[ebuild  N    ] dev-python/gnome-python-extras-2.14.0-r1  USE="X firefox -debug 

-doc -seamonkey" 339 kB 

[ebuild  N    ] dev-util/meld-1.1.3  USE="-debug -doc" 583 kB 

[ebuild  N    ] app-text/rman-3.2  77 kB 

[ebuild  N    ] x11-themes/gentoo-xcursors-0.3.1  1,168 kB 

[ebuild  N    ] x11-apps/xdriinfo-1.0.1  USE="-debug" 79 kB 

[ebuild  N    ] x11-misc/xorg-cf-files-1.0.2  USE="-debug" 258 kB 

[ebuild  N    ] x11-misc/imake-1.0.2  USE="-debug" 110 kB 

[ebuild  N    ] x11-libs/libXvMC-1.0.2  USE="-debug" 224 kB 

[ebuild  N    ] x11-libs/libXprintUtil-1.0.1  USE="-debug" 218 kB 

[ebuild  N    ] x11-libs/libXprintAppUtil-1.0.1  USE="-debug" 203 kB 

[ebuild  N    ] x11-apps/xsetroot-1.0.1  USE="-debug" 75 kB 

[ebuild  N    ] x11-apps/xcursorgen-1.0.1  USE="-debug" 80 kB 

[ebuild  N    ] x11-themes/xcursor-themes-1.0.1  USE="-debug" 2,204 kB 

[ebuild  N    ] x11-libs/libXevie-1.0.1  USE="-debug" 219 kB 

[ebuild  N    ] x11-libs/libXTrap-1.0.0  USE="-debug" 214 kB 

[ebuild  N    ] x11-apps/sessreg-1.0.0  USE="-debug" 80 kB 

[ebuild  N    ] x11-apps/xdm-1.0.5  USE="ipv6 pam -debug -xprint" 355 kB 

[ebuild  N    ] x11-libs/libFS-1.0.0  USE="ipv6 -debug" 231 kB 

[ebuild  N    ] x11-libs/liboldX-1.0.1  USE="-debug" 210 kB 

[ebuild  N    ] x11-misc/gccmakedep-1.0.2  USE="-debug" 68 kB 

[ebuild  N    ] virtual/x11-7.0-r2  USE="dri" 0 kB 

[ebuild  N    ] x11-misc/sux-1.0-r2  9 kB 

[ebuild  N    ] app-portage/cfg-update-1.8.0-r3  USE="gnome kde" 32 kB 

Total size of downloads: 174,466 kB

Would you like to merge these packages? [Yes/No]
```

----------

## Maedhros

That's due to the gnome and kde USE flags, I would have thought. You can see more clearly what depends on what by using the --tree option with emerge.

----------

## xentric

 *HXC wrote:*   

> Though I would like some additional  information about using xxdiff. If I get that screen in front of mee I don't have a clue about what to do next. Now I check the diffrences between the left and the rightpane. and decide whicgh which one l like to keep.

 

Just read the first post of this thread, the section "Screenshots and usage" explains that you simply click on the yellow and green colored lines in xxdiff to select which ones should be put in the merged result... Pink will be included, blue will be discarded. After clicking all colored areas you can save the result with the "M"-button and cfg-update will replace the old config file with the merged result. The manpage ($ man cfg-update) also contains some usage instructions.

 *Quote:*   

> Another problem I encountered is the 'high requirements' of cfg-update. When trying to install on a newly installed system with fluxbox running I get this longs list:

 

Maedhros is right, if you specify -kde and -gnome USE-flags during installation, cfg-update won't need all those dependencies but the result is that you won't be able to use xxdiff or meld for updating. If you use -kde -gnome during installation cfg-update will default to sdiff for merging the config files with the ._cfg0000_ files. (sdiff is the commandline diff/merge tool which is also used by etc-update for interactive merging)

It's all explained in the first post of this thread...

----------

## chovy

emerge -avt cfg-update

 *Quote:*   

> 
> 
> make -C po
> 
> make[1]: Entering directory `/var/tmp/portage/meld-1.1.3/work/meld-1.1.3/po'
> ...

 

Can't emerge meld?

----------

## xentric

 *chovy wrote:*   

> Can't emerge meld?

 I can't help you with the build error, can't find anything about it in the Forums or on Google.

But you can set the -gnome USE-flag so meld won't be compiled as a dependency...

Just do this before emerging cfg-update:

```
echo app-portage/cfg-update -kde -gnome >> /etc/portage/package.use
```

After emerging cfg-update, you can separately emerge the tools you would like to try. That way you can use cfg-update with other mergetools like xxdiff, kdiff3, gtkdiff, gvimdiff, vimdiff, etc... until you find the problem that prevents you from successfully emerging meld.

Note: vimdiff and gvimdiff are not yet supported, but you only need to insert two lines of code into the cfg-update script to make them work. They will be supported by the next version which will probably hit the mirrors in about two weeks. See this post for the two lines of code and instructions on how to use (g)vimdiff with cfg-update.

----------

## devsk

I got this:

```
$ emerge -pv gnome

Nested quantifiers in regex; marked by <-- HERE in m/app-benchmarks:bonnie++ <-- HERE -1.93c:20060828-032906.log/ at /usr/bin/cfg-update line 759.

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

FLAGS

  -d, --debug

          Debugging, unhides STDERR messages and shows subroutine tags

  -a, --automatic-only

          Skips manual updates (for use with cronjobs)

  -m, --manual-only

          Skips automatic updates

  -t, --tool /path/tool

          Set tool, overrides the default tool setting in /etc/cfg-update.conf

  -p, --pretend

          Pretend, simulate the update session without changing anything

  -v, --verbose

          Verbose output, shows all file operations and unhides STDERR messages

RUNMODES

  -l, --list

          List updates (._cfg????_* files) including modification state

  -u, --update

          Update the protected configuration files

  -b, --backups

          List backup files, with numbers for use with the -r option

  -r, --restore [n]

          Restore a backup by using a number from the -b output

  -s, --show-protected-dirs

          Shows directories protected by the CONFIG_PROTECT system variable

  -i, --index

          Create or update the checksum-index

  --on

          Enable integration with the emerge command (alias in /root/.bashrc)

  --off

          Disable integration with the emerge command (alias in /root/.bashrc)

MERGETOOL

  xxdiff  (manual 3-way merging is supported)

INFORMATION

  Start (as root) with "cfg-update -l" to list all the ._cfg????_* files,

  followed by "cfg-update -u" to update the current config files one by one.

  You can also use the --pretend mode with "cfg-update -p -u" to see how

  cfg-update will handle the files and optionally add "-t diff" to take a

  quick look at the differences between the files...

  In xxdiff, select the lines you want to keep/add by clicking on them.

  Save the merged result by clicking on the "save as merged" [M] button.

  After closing xxdiff, cfg-update will replace the current config file with

  the .merge file you have just created. Backups are made automatically, so

  you can always restore the previous version of a config file if the new

  version causes any problems...

SETTINGS (from /etc/cfg-update.conf)

  << Stage1 >>  Automatic replacing     - enabled

  << Stage2 >>  Automatic 3-way merging - enabled

  << Stage3 >>  Manual 3-way merging    - enabled

  << Stage4 >>  Manual 2-way merging    - enabled

  << Stage5 >>  Manual replacing        - enabled

For more info, type: man cfg-update

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] gnome-base/gnome-2.14.2  USE="cdr dvdr hal -accessibility" 0 kB

Total size of downloads: 0 kB

```

It seems like cfg-update doesn't like '++' in package names(as in bonnie++), it clashes with some regexp processing.

I am not sure if printing the man page on some internal error is a good idea.

----------

## xentric

 *devsk wrote:*   

> It seems like cfg-update doesn't like '++' in package names(as in bonnie++), it clashes with some regexp processing.

 Thanks for reporting this!

I've been able to reproduce this on my machine. When the most recent .log file in /var/log/portage has "++" in the filename it chokes on it. I've fixed this in the new version (will be released soon) by stripping the "++" before any matching is done.

You can fix your issue by removing that portage log file:

```
rm /var/log/portage/app-benchmarks:bonnie++-1.93c:20060828-032906.log
```

 *Quote:*   

> I am not sure if printing the man page on some internal error is a good idea.

 This is not done intentionally, the script somehow manages to skip a section of code that would make it exit cleanly. It looks like perl kills the subroutine that produces this error upon matching, but aparently it also kills the parent subroutine that called the broken subroutine. So it skips the explicit "exit;" at the end of the parent subroutine and continues with the next subroutine which happends to be "print_usage"... Very weird behaviour!

----------

## chovy

put your man page at the bottom of your perl script after

```
#!/usr/bin/perl -w

print "foo";

__END__

=pod

=head1 FOO()

=head1 Anthony Ettinger

This is a demo of documenting with __END__

=cut

```

It will stop interpreting perlcode at that point. saves execution time if you have a big documentation section.

Then you can view the documetnation with ~$ perldoc foo.pl

----------

## xentric

 *chovy wrote:*   

> It will stop interpreting perlcode at that point. saves execution time if you have a big documentation section.
> 
> Then you can view the documetnation with ~$ perldoc foo.pl

 I want the script to display the usage instructions when it's called without (or with wrong) arguments. And I want to keep things as standard as possible for users, so calling "man cfg-update" will give them the man page. Most users are not familiar with the perldoc functionality.

I have fixed this issue by setting a new variable $indexing_completed to "undefined" in the main loop.

When starting the index_mode subroutine, the variable is set to "false" and at the end of the

subroutine it's set to "true". So when an error occurs and code is skipped, the next step in the

main loop is a line that checks if $indexing_complete is "false". If it is, it exits the script.

I admit this ain't pretty, but it effectively does the trick while keeping the rest of the script-flow intact.

----------

## devsk

why is it looking at last log file in /var/log/portage/? just curious. Because if you are trying to find who emerged last, then /var/log/emerge.log may be better source. How about if current system time or the timestamps are messed on the file system? (in both cases last is not really the last)

----------

## xentric

 *devsk wrote:*   

> why is it looking at last log file in /var/log/portage/? just curious.

 cfg-update needs to update the checksum-index with the MD5-checksums of the configfiles of newly merged packages before a new version of those packages will be emerged because Portage overwrites the old checksum upon installing a new version. If that happends cfg-update can't determine if the current file was modified or not... That's why I needed to create an alias for the emerge command that runs cfg-update first, followed by emerge itself.

cfg-update needs to know which package is emerged last. If it the last emerged package is still the same, cfg-update can skip indexing so there won't be unnecessary 10+ second lag due to indexing on every emerge command...

 *Quote:*   

> /var/log/emerge.log may be better source. How about if current system time or the timestamps are messed on the file system? (in both cases last is not really the last)

 You have a point. At the time I looked at the emerge.log file and decided it was easier to use 

```
ls -t /var/log/portage | head -n1
```

to get the last emerged package.

But I just tried the following command to get the last emerged package:

```
cat /var/log/emerge.log | grep ">>> emerge" | tail -n 1 | awk {'print $1$7'}
```

seems to work just as well, so I'll put that in the new version.

Thanks!

----------

## devsk

 *xentric wrote:*   

> 
> 
> But I just tried the following command to get the last emerged package:
> 
> ```
> ...

 

Or you could try the the awk only version (no grep or tail):

```
awk '/>>> emerge/' /var/log/emerge.log |awk 'END{print $1$7}'
```

----------

## devsk

I just timed the operations. grep seems faster than awk in finding regukar expressions in the text:

```
$ time grep ">>> emerge" /var/log/emerge.log > /dev/null

real    0m0.005s

user    0m0.005s

sys     0m0.001s

$ time awk '/>>> emerge/' /var/log/emerge.log > /dev/null

real    0m0.024s

user    0m0.018s

sys     0m0.002s

```

repeated several times to rule out caching effect.

So, the best is:

```
grep ">>> emerge" /var/log/emerge.log | awk 'END{print $1$7}'
```

it executes in 6ms on my system, compared to 14ms for your one-liner and 25ms for awk-only one liner. These will be much slower on bigger emerge.log files and slower systems than mine. Remember, emerge.log only grows, so optimize as much as you can... :Very Happy: 

BTW, just for comparison sake:

```
$ time ls -t /var/log/portage | head -n1

media-sound:sox-12.17.9:20060824-233815.log

real    0m0.041s

user    0m0.016s

sys     0m0.027s

```

PPS: How do you account for people who have /var/log/portage disabled i.e. logging disabled because /etc/make.conf doesn't have /var/log/portage or directory /var/log/portage is not even present, in your original code (I mean in the current code before you move to one of these emerge.log thingies)?

----------

## xentric

 *devsk wrote:*   

> So, the best is:
> 
> ```
> grep ">>> emerge" /var/log/emerge.log | awk 'END{print $1$7}'
> ```
> ...

 Thanks a lot for your help on this, excellent!

 *Quote:*   

> PPS: How do you account for people who have /var/log/portage disabled i.e. logging disabled because /etc/make.conf doesn't have /var/log/portage or directory /var/log/portage is not even present, in your original code (I mean in the current code before you move to one of these emerge.log thingies)?

 The script checks if PORT_LOGDIR is set in /etc/make.conf

If it isn't set the script prints some text recommending the user to:

A. enable the PORTLOG variable in /etc/make.conf 

or

B. use the bash_helper or php_helper scripts submitted by other users to avoid unnecessary indexing.

I have just removed this check from the new version as it becomes obsolete when we use /var/log/emerge.log to determine if indexing is needed  :Very Happy: 

Hey, you seem pretty creative with your solutions, maybe you (or someone else) can point me in the right direction with two other issues that still bug me:

1. cfg-update checks if a GUI is available before it spawns the GUI tool:

Currently the script checks if the DISPLAY variable is set, by calling "echo $DISPLAY"

If it is not empty, it will assume that X is running and it's possible to spawn a GUI tool like xxdiff.

I figured that X can be running without having a local display, so it's not good enough to simply

check if there's a process running with X as it's name... that's why I check the DISPLAY variable.

Maybe there's a better method?

2. cfg-update creates an alias for the emerge command in /root/.bashrc which calls a wrapperscript

that first runs "cfg-update --index" and then continues with the actual emerge command.

This isn't a nice way to ensure that the index stays up to date...

I have considered cronjobs, looked for a "pre-emerge hook" in portage but have not found

a good alternative for running "cfg-update --index" right before an emerge command.

Maybe you have some ideas?

----------

## Rick

 *xentric wrote:*   

> 1. cfg-update checks if a GUI is available before it spawns the GUI tool:
> 
> Currently the script checks if the DISPLAY variable is set, by calling "echo $DISPLAY"
> 
> If it is not empty, it will assume that X is running and it's possible to spawn a GUI tool like xxdiff.
> ...

 Checking for $DISPLAY is _the_ method to use. But there are other methods too, for example you could look at the $TERM variable, or the $TTY

----------

## ppurka

 *devsk wrote:*   

> I just timed the operations. grep seems faster than awk in finding regukar expressions in the text:
> 
> ...
> 
> 

 It is strange, but here are the results on my system:

```
~> time grep ">>> emerge" /var/log/emerge.log > /dev/null

grep ">>> emerge" /var/log/emerge.log > /dev/null  5.45s user 0.03s system 99% cpu 5.513 total

~> time awk '/>>> emerge/' /var/log/emerge.log > /dev/null

awk '/>>> emerge/' /var/log/emerge.log > /dev/null  0.27s user 0.01s system 99% cpu 0.283 total

~> time grep ">>> emerge" /var/log/emerge.log | awk 'END{print $1$7}'

1156651120:net-nds/ypbind-1.19.1

grep ">>> emerge" /var/log/emerge.log  5.41s user 0.03s system 98% cpu 5.525 total

awk 'END{print $1$7}'  0.00s user 0.00s system 0% cpu 5.476 total

```

Size of /var/log/emerge.log: 

```
~> ls -l /var/log/emerge.log 

-rw-rw---- 1 portage portage 2645019 2006-08-26 23:58 /var/log/emerge.log

~> hdparm -tT /dev/sda                                                                                      <root

/dev/sda:

 Timing cached reads:   2120 MB in  2.00 seconds = 1059.76 MB/sec

 Timing buffered disk reads:  130 MB in  3.04 seconds =  42.75 MB/sec

```

Here is something else which I found interesting:

```
~> time tac /var/log/emerge.log| sed -n '/>>> emerge/{p;q;}'                                                <root

1156651120:  >>> emerge (3 of 3) net-nds/ypbind-1.19.1 to /

tac /var/log/emerge.log  0.00s user 0.00s system 34% cpu 0.003 total

sed -n '/>>> emerge/{p;q;}'  0.00s user 0.00s system 77% cpu 0.001 total

```

----------

## xentric

 *Rick wrote:*   

> Checking for $DISPLAY is _the_ method to use. But there are other methods too, for example you could look at the $TERM variable, or the $TTY

 Thanks! Keeping in mind that there are lot's of different terminal-types so I guess sticking with the DISPLAY variable is pretty safe and much easier.

ppurka: Here are my results:

```
root@gentoo 852MHz 68C xentric # ls -l /var/log/emerge.log

-rw-rw---- 1 portage portage 2011494 Aug 29 02:39 /var/log/emerge.log

root@gentoo 852MHz 69C portage # hdparm -Tt /dev/hda

/dev/hda:

 Timing cached reads:   444 MB in  2.01 seconds = 220.41 MB/sec

 Timing buffered disk reads:   52 MB in  3.00 seconds =  17.32 MB/sec

root@gentoo 852MHz 65C xentric # time awk '/>>> emerge/' /var/log/emerge.log > /dev/null

real    0m0.111s

user    0m0.058s

sys     0m0.017s

root@gentoo 852MHz 65C xentric # time grep ">>> emerge" /var/log/emerge.log > /dev/null

real    0m0.022s

user    0m0.012s

sys     0m0.003s
```

Note: this is on an old Pentium3 850Mhz laptop with 256Mb RAM and a slow HD...

(I've tested this multiple times to avoid caching differences)

Try this:

```
time LC_ALL="C" grep ">>> emerge" /var/log/emerge.log | awk 'END{print $1$7}'
```

does that speed up grepping? It seems that locales like UTF-8 slow down grep a lot... (see grep manpage about LC_ALL)

The cfg-update script actually sets the locale to C in every subroutine that uses grep...

----------

## ppurka

You were right.  I have utf-8 set in my LC_*. Here are the new statistics with LC_ALL="C",- grep sure takes way lower time than awk, but the sed beats them both, with far less cpu (btw, it is a  2.2GHz Athlon XP 3200+).  :Smile:   I was just thinking you must be having a super fast system there with a 15000 rpm hard disk to get such low numbers.    :Laughing: 

```
~> time LC_ALL="C" grep ">>> emerge" /var/log/emerge.log > /dev/null                                        

LC_ALL="C" grep ">>> emerge" /var/log/emerge.log > /dev/null  0.00s user 0.00s system 95% cpu 0.007 total

~> time LC_ALL="C" awk '/>>> emerge/' /var/log/emerge.log > /dev/null                                        

LC_ALL="C" awk '/>>> emerge/' /var/log/emerge.log > /dev/null  0.02s user 0.00s system 97% cpu 0.029 total

~> time LC_ALL="C" tac /var/log/emerge.log| sed -n '/>>> emerge/{p;q;}'                          

1156651120:  >>> emerge (3 of 3) net-nds/ypbind-1.19.1 to /

LC_ALL="C" tac /var/log/emerge.log  0.00s user 0.00s system 39% cpu 0.003 total

sed -n '/>>> emerge/{p;q;}'  0.00s user 0.00s system 78% cpu 0.001 total

```

----------

## xentric

 *ppurka wrote:*   

> grep sure takes way lower time than awk, but the sed beats them both, with far less cpu

 You're right! It takes less time on my system too:

```
root@gentoo 852MHz 68C portage # time tac /var/log/emerge.log| sed -n '/>>> emerge/{p;q;}'

1156811850:  >>> emerge (1 of 1) app-misc/beep-1.2.2 to /

real    0m0.009s

user    0m0.003s

sys     0m0.005s
```

So I've put this in the new version of the script   :Very Happy: 

Next thing is to speed up creating the index... LOL

I currently use:

```
root@gentoo 852MHz 75C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' >> /tmp/checksum-index

real    0m9.742s

user    0m1.989s

sys     0m0.650s
```

Any ideas? 

(BTW, I'm gonna take a nap... it's 05:42am... oops!)

----------

## devsk

cut is faster for this particular case because it is pretty plain set of args:

```

$ time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/tmper.idx

real    0m0.287s

user    0m0.292s

sys     0m0.148s

$ time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' > /tmp/tmper.idx2

real    0m0.576s

user    0m0.548s

sys     0m0.140s

$ l /tmp/tmper.idx*

-rw-r--r-- 1 devsk users 18622047 Aug 28 23:06 /tmp/tmper.idx

-rw-r--r-- 1 devsk users 18834722 Aug 28 23:04 /tmp/tmper.idx2

```

It also creates a smaller index...  :Razz: 

```
$ bc

bc 1.06.94

Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.

This is free software with ABSOLUTELY NO WARRANTY.

For details type `warranty'. 

18834722-18622047

212675
```

```
$ wc -l /tmp/tmper.idx*

  212675 /tmp/tmper.idx

  212675 /tmp/tmper.idx2

  425350 total

```

one blank character (which you inserted for an unknown reason) less per line. Otherwise perfect match.

The gains might be larger for slower systems. post your numbers please. I wanna see if its faster than 10 seconds you get currently.

----------

## swimmer

The problem is more the 'first shot' - when you index after a longer time it 

takes quite a time to get through /var/db/pkg ... but don't ask me why - I only 

notice that and do not understand  :Wink: 

First run: *Quote:*   

> 
> 
> #> time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/tmper.idx 
> 
> real    0m17.422s             
> ...

 

Second run: *Quote:*   

> 
> 
> #> time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/tmper.idx
> 
> real    0m0.606s              
> ...

 

The differences between awk and cut aren't as big ...

Greetz

swimmer

----------

## xentric

 *devsk wrote:*   

> cut is faster for this particular case because it is pretty plain set of args:
> 
> ...
> 
> The gains might be larger for slower systems. post your numbers please. I wanna see if its faster than 10 seconds you get currently.

 

cut is a little bit faster on my old system too:

```
*** YESTERDAY ***

root@gentoo 852MHz 68C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' >> /tmp/checksum-index

real    0m10.764s

user    0m1.896s

sys     0m0.606s

root@gentoo 852MHz 72C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' >> /tmp/checksum-index

real    0m10.110s

user    0m1.973s

sys     0m0.625s

root@gentoo 852MHz 75C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' >> /tmp/checksum-index

real    0m9.742s

user    0m1.989s

sys     0m0.650s

*** TODAY ***

root@gentoo 852MHz 70C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/checksum-index2

real    0m10.017s

user    0m1.431s

sys     0m0.639s

root@gentoo 852MHz 67C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/checksum-index2

real    0m4.482s

user    0m1.458s

sys     0m0.441s

root@gentoo 852MHz 62C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/checksum-index2

real    0m2.382s

user    0m1.486s

sys     0m0.369s

root@gentoo 852MHz 63C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/checksum-index2

real    0m2.428s

user    0m1.457s

sys     0m0.408s

root@gentoo 852MHz 64C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' >> /tmp/checksum-index

real    0m3.299s

user    0m1.862s

sys     0m0.431s

root@gentoo 852MHz 70C portage # time grep "^obj " /var/db/pkg/*/*/CONTENTS | awk '{ print $2"  "$3 }' >> /tmp/checksum-index

real    0m3.037s

user    0m1.884s

sys     0m0.423s
```

On the first run both methods take about 12 seconds to complete. Look at the effect that caching has on the timings... looks like there are a lot of factors that have impact on this kind of benchmarking. Today the awk method is a lot faster after chaching.

The awk method goes down to 5 seconds after a couple of runs and the cut method does it in 4 seconds.

The cut method is a little bit better, so I'll stick to that. Thanks   :Very Happy: 

----------

## xentric

 *swimmer wrote:*   

> The problem is more the 'first shot' - when you index after a longer time it 
> 
> takes quite a time to get through /var/db/pkg ... but don't ask me why - I only 
> 
> notice that and do not understand 

 

I think that's due to caching. The stuff in /var/db/pkg remains in RAM after the first run, so on sebsequent runs your system can use this data which is already in RAM. That's way faster than your HD.

Just for fun, look on the forums for "shake your files". That method is used to force files into RAM so programs start up a bit faster.

 *Quote:*   

> First run:
> 
> ```
> 
> #> time grep "^obj " /var/db/pkg/*/*/CONTENTS | cut -d" " -f2-3 > /tmp/tmper.idx 
> ...

 Looking at your subsequent runs it seems like you have a pretty fast system but it's horribly slow when it uses the HD, maybe you haven't got DMA enabled on your HD? That usually makes it a lot slower. Can you tell me what your system specs are? It makes me curious to see what you get when you execute the hdparm throughput-test command:

```
[root@gentoo 852MHz 56C portage # ls -l /var/log/emerge.log

-rw-rw---- 1 portage portage 2012089 Aug 29 06:11 /var/log/emerge.log

root@gentoo 852MHz 56C portage # hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media

        Model Number:       TOSHIBA MK8026GAX

        Serial Number:      65TL1869T

        Firmware Revision:  PA001G

Standards:

        Supported: 6 5 4 3

        Likely used: 6

Configuration:

        Logical         max     current

        cylinders       16383   17475

        heads           16      15

        sectors/track   63      63

        --

        CHS current addressable sectors:   16513875

        LBA    user addressable sectors:  156301488

        device size with M = 1024*1024:       76319 MBytes

        device size with M = 1000*1000:       80026 MBytes (80 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 48     Queue depth: 1

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Advanced power management level: unknown setting (0x0080)

        DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    NOP cmd

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    Mandatory FLUSH CACHE command

           *    Device Configuration Overlay feature set

                SET MAX security extension

           *    Advanced Power Management feature set

           *    SMART self-test

           *    SMART error logging

Security:

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

        58min for SECURITY ERASE UNIT.

HW reset results:

        CBLID- above Vih

        Device num = 0 determined by the jumper

Checksum: correct

root@gentoo 852MHz 56C portage # hdparm -Tt /dev/hda

/dev/hda:

 Timing cached reads:   588 MB in  2.01 seconds = 292.51 MB/sec

 Timing buffered disk reads:   62 MB in  3.03 seconds =  20.49 MB/sec

root@gentoo 852MHz 59C portage # hdparm -Tt /dev/hda

/dev/hda:

 Timing cached reads:   588 MB in  2.01 seconds = 292.77 MB/sec

 Timing buffered disk reads:   62 MB in  3.09 seconds =  20.09 MB/sec

root@gentoo 852MHz 57C portage # hdparm -Tt /dev/hda

/dev/hda:

 Timing cached reads:   592 MB in  2.01 seconds = 294.30 MB/sec

 Timing buffered disk reads:   60 MB in  3.00 seconds =  19.98 MB/sec
```

This is a 2,5" laptop HD: 80Gb with 16Mb cache and 5400 RPM. So if you have a 7200 RPM 3,5" HD you should get better results.

This is my setting for /dev/hda in /etc/conf.d/hdparm:

```
disc0_args="-c1 -d1 -m16 -u1 -X66"
```

Caution: do not use the -X66 unless you are sure that your HD can handle it. Maybe you have a newer driver that supports even better like -X69 (=udma5). Just check "man hdparm" for the -X option. It needs to be (udma_level+64), so mine uses udma2.

----------

## swimmer

 *xentric wrote:*   

> [...]
> 
> I think that's due to caching. The stuff in /var/db/pkg remains in RAM after the first run, so on sebsequent runs your system can use this data which is already in RAM. That's way faster than your HD.

 

... I see

 *xentric wrote:*   

> Looking at your subsequent runs it seems like you have a pretty fast system but it's horribly slow when it uses the HD, maybe you haven't got DMA enabled on your HD? That usually makes it a lot slower. Can you tell me what your system specs are? It makes me curious to see what you get when you execute the hdparm throughput-test command [...]

 

Hmmm - I have a SATA disk and I thought it's not necessary to optimize it with 

hdparm since this happens automatically. Correct me if I'm wrong ...

```
swimmer ~ # hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media

        Model Number:       Maxtor 6Y250M0

        Serial Number:      Y69GHVVE

        Firmware Revision:  YAR511W0

Standards:

        Supported: 7 6 5 4

        Likely used: 7

Configuration:

        Logical         max     current

        cylinders       16383   16383

        heads           16      16

        sectors/track   63      63

        --

        CHS current addressable sectors:   16514064

        LBA    user addressable sectors:  268435455

        LBA48  user addressable sectors:  490234752

        device size with M = 1024*1024:      239372 MBytes

        device size with M = 1000*1000:      251000 MBytes (251 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        Queue depth: 1

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 1

        Advanced power management level: unknown setting (0x0000)

        Recommended acoustic management value: 192, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    NOP cmd

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    FLUSH CACHE EXT command

           *    Mandatory FLUSH CACHE command

           *    Device Configuration Overlay feature set

           *    48-bit Address feature set

           *    Automatic Acoustic Management feature set

                SET MAX security extension

                Advanced Power Management feature set

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

Security:   

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

Checksum: correct

swimmer ~ # hdparm -tT /dev/sda

            

/dev/sda:   

 Timing cached reads:   3528 MB in  2.00 seconds = 1763.81 MB/sec

 Timing buffered disk reads:  168 MB in  3.02 seconds =  55.72 MB/sec

swimmer ~ # hdparm -tT /dev/sda

            

/dev/sda:   

 Timing cached reads:   3520 MB in  2.00 seconds = 1759.04 MB/sec

 Timing buffered disk reads:  168 MB in  3.03 seconds =  55.48 MB/sec

swimmer ~ # hdparm -tT /dev/sda

            

/dev/sda:   

 Timing cached reads:   3496 MB in  2.00 seconds = 1747.62 MB/sec

 Timing buffered disk reads:  170 MB in  3.02 seconds =  56.22 MB/sec

swimmer ~ # ll /var/log/emerge.log 

-rw-rw---- 1 portage portage 2226909 Aug 29 07:44 /var/log/emerge.log

swimmer ~ # 

```

Looks ok to me  :Wink: 

Greetz

swimmer

----------

## xentric

 *swimmer wrote:*   

> Hmmm - I have a SATA disk and I thought it's not necessary to optimize it with 
> 
> hdparm since this happens automatically. Correct me if I'm wrong ...
> 
> ...
> ...

 Yeah, that sure looks good!

Pretty weird that it takes your system about 18 seconds on the first run.

I have /var on a reiser3 filesystem mounted with noatime,nodiratime,notail.

As /var/db/pkg contains lot's of small files, I guess this is where reiserfs with notail makes a difference.

----------

## devsk

 *xentric wrote:*   

> 
> 
> 1. cfg-update checks if a GUI is available before it spawns the GUI tool:
> 
> Currently the script checks if the DISPLAY variable is set, by calling "echo $DISPLAY"
> ...

 The right way of checking is thru both DISPLAY and xhost, like:

```
if ( [[ -z ${DISPLAY} ]] || ! (xhost &>/dev/null) ) ; then echo DISPLAY_NOTTHERE; else echo DISPLAY_PRESENT;fi
```

So, if DISPLAY is set but user (root can't connect because Joe user didn't do xhost +) can't connect to it, DISPLAY_NOTTHERE will be echoed in this case. xhost fails in few seconds if it can't connect to $DISPLAY. Of course, the check comes out immd. with DISPLAY_NOTTHERE if DISPLAY variable is not set.

----------

## xentric

 *devsk wrote:*   

> So, if DISPLAY is set but user (root can't connect because Joe user didn't do xhost +) can't connect to it, DISPLAY_NOTTHERE will be echoed in this case. xhost fails in few seconds if it can't connect to $DISPLAY. Of course, the check comes out immd. with DISPLAY_NOTTHERE if DISPLAY variable is not set.

 

Well, I have tried to test this but all I get when I run xhost without any arguments is a message that access control is enabled. It seems like I can't disable access control so I can't test your line of bash-code.

If I run "xhost -localhost" or "xhost -" (with user that started the X server) I still get the same message when I run "xhost" as root. I can't find a file containing an accesslist or anything. The manpage is refering to /etc/X*.hosts but I have no such files.

Next week I'll (finally) get a brand spanking new Core2Duo system on which I will start from scratch by installing the new 2006.1. That's also a good opportunity to test installing cfg-update on a default setup. I'll check if xhost exits with a STDERR message.

----------

## devsk

 *xentric wrote:*   

>  *devsk wrote:*   So, if DISPLAY is set but user (root can't connect because Joe user didn't do xhost +) can't connect to it, DISPLAY_NOTTHERE will be echoed in this case. xhost fails in few seconds if it can't connect to $DISPLAY. Of course, the check comes out immd. with DISPLAY_NOTTHERE if DISPLAY variable is not set. 
> 
> Well, I have tried to test this but all I get when I run xhost without any arguments is a message that access control is enabled. It seems like I can't disable access control so I can't test your line of bash-code.
> 
> If I run "xhost -localhost" or "xhost -" (with user that started the X server) I still get the same message when I run "xhost" as root. I can't find a file containing an accesslist or anything. The manpage is refering to /etc/X*.hosts but I have no such files.
> ...

 the test that I posted checks for exit code of xhost. Try 

```
DISPLAY=random_host_does_not_exist:0 xhost &>/dev/null

echo $?

```

 exit code indicates if xhost succeeded or failed in getting a status of access control of the X. without any arguments it gives a status if the access control is enabled or disabled. This is easily verified by 'su' in as root in joe's running X xterm. Then type 'xhost'. It will give the status. In another xterm as user joe, do 'xhost -', followed by a 'xhost' in 'su' xterm, followed by 'xhost +' in joe's xterm, followed by 'xhost' in 'su' xterm. You will see status changes in 'su' window.

Trust me that test works if copied verbatim. Just replace the 'echo' commands with whatever you wanna do if X is available and otherwise.

----------

## xentric

 *devsk wrote:*   

> Trust me that test works if copied verbatim. Just replace the 'echo' commands with whatever you wanna do if X is available and otherwise.

 

```
* did "xhost +" in other terminal

        root@gentoo 852MHz 48C / # xhost

        access control disabled, clients can connect from any host

* did "xhost -" in other terminal

        root@gentoo 852MHz 48C / # xhost

        access control enabled, only authorized clients can connect

* did "xhost +localhost" in other terminal

        root@gentoo 852MHz 48C / # xhost

        access control enabled, only authorized clients can connect

        INET:gentoo.homelinux

* test with unknown host

        root@gentoo 852MHz 48C / # DISPLAY=foobar:0 xhost &>/dev/null; echo $?

        1

* test with empty DISPLAY variable

        root@gentoo 852MHz 48C / # DISPLAY= xhost &>/dev/null; echo $?

        1

* test with correct DISPLAY variable

        root@gentoo 852MHz 48C / # DISPLAY=:0 xhost &>/dev/null; echo $?

        0
```

Verified and works, I will use this in the new version of the script.

Thanks a lot devsk!

----------

## devsk

 *xentric wrote:*   

> Verified and works, I will use this in the new version of the script.

 

please don't forget to test for the $DISPLAY first and xhost after that, just to optimise the case when DISPLAY isn't even set. Otherwise, cfg-update -u will seem like hung for few seconds because xhost will take few seconds to come out.

 *xentric wrote:*   

> 
> 
> Thanks a lot devsk!

 You are very welcome.

----------

## xentric

 *devsk wrote:*   

> Otherwise, cfg-update -u will seem like hung for few seconds because xhost will take few seconds to come out.

 I don't get any delay when running xhost if I unset the DISPLAY variable, nor when it is set but doesn't contain a value or when it contains an invalid value... it responds immediately with errorcode 0 or 1.

Does xhost "hang" while waiting for a timeout on your system?

I can put the following check in the update_files subroutine:

```
if ((using GUI mergetool) and (xhost returns errorcode 1)) {

    print: GUI is unavailable...

    print: if X is installed, run cfg-update in X-terminal otherwise use "-t sdiff" or "-t vimdiff"

    print: if this fails while using an X-terminal, check xhost accesscontrol and DISPLAY variable

    print: if X is not installed, set MERGETOOL in /etc/cfg-update.conf to "sdiff" or "vimdiff"

    print: do you want to [q]uit or continue with [s]diff or [v]imdiff ?

    read keypress

}
```

This is my preferred way to go... even if xhost "hangs" when trying to connect to the X-server.

PS. I'll treat gvimdiff as a CLI tool because if you run it while X is not available it simply falls back to vimdiff automatically. That's actually pretty cool  :Smile: 

----------

## XenoTerraCide

hmm... cfg-update used to work for me but lately it's not finding the graphical updater has something changed that I would need to update? I'm using kdiff3 (which is installed) and have it set

```
MERGETOOL = /usr/bin/kdiff3

```

 anything wrong with this?

----------

## xentric

 *XenoTerraCide wrote:*   

> hmm... cfg-update used to work for me but lately it's not finding the graphical updater has something changed that I would need to update? I'm using kdiff3 (which is installed) and have it set
> 
> ```
> MERGETOOL = /usr/bin/kdiff3
> 
> ...

 

First of all, try "sux" (instead of "su" or "sudo") to become root in your Xterminal, and check if cfg-update can launch the GUI tool. If that works, it probably is simple to fix with some basic troubleshooting:

Try running "cfg-update -vu". The -v option unhides STDERR messages that could give some clues about not being able to start the GUI tool...

Try "xhost +localhost" (as the user who started the X server) and then log in with root and try cfg-update.

Or check if the DISPLAY variable is properly set with "env | grep DISPLAY", it should return something like DISPLAY=:0

Running "source /etc/profile" (when logged in as root as root) before you start cfg-update could also work.

Please post some feedback if you find out what changed, maybe it helps other users with similar problems.

----------

## XenoTerraCide

DISPLAY variable is missing... other than that... don't know yet. will try sux as soon as I can figure out why I can't authenticate with su or sux via password...

----------

## joyping

hi,

i get this now after reemerging libsigc++:

cfg-update --index

Nested quantifiers in regex; marked by <-- HERE in m/dev-libs:libsigc++ <-- HERE -2.0.16:20061002-150435.log/ at /usr/bin/cfg-update line 759.

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

FLAGS

  -d, --debug

          Debugging, unhides STDERR messages and shows subroutine tags

  -a, --automatic-only

          Skips manual updates (for use with cronjobs)

  -m, --manual-only

          Skips automatic updates

  -t, --tool /path/tool

          Set tool, overrides the default tool setting in /etc/cfg-update.conf

...

i have also problems with meld and 3way merge. maybe i don't understand the 3way mechanism anyway.

btw. what about setting up a webpage or at least a wiki for cfg-update?

----------

## devsk

 *joyping wrote:*   

> hi,
> 
> i get this now after reemerging libsigc++:
> 
> cfg-update --index
> ...

 

this is the regex thing that I pointed out earlier. I think it was agreed that using the last log file in /var/log/portage/ was a bad idea and we would be using /var/log/emerge.log to determine last emerged package. When are we going to see the updated version? I think this error is serious enough to warrant a new release, maybe an -r4.... :Smile: 

----------

## xentric

 *joyping wrote:*   

> Nested quantifiers in regex; marked by <-- HERE in m/dev-libs:libsigc++ <-- HERE -2.0.16:20061002-150435.log/ at /usr/bin/cfg-update line 759....
> 
> i have also problems with meld and 3way merge. maybe i don't understand the 3way mechanism anyway.
> 
> btw. what about setting up a webpage or at least a wiki for cfg-update?

 

The error will only occur when the last packages that was merged contains ++ in the name.

I have already fixed this in the new version of cfg-update, but it needs some more testing on other points.

Devsk is right, I should release 1.8.0-r4 soon   :Very Happy: 

Will work on it next sunday... don't promise anything though. I hate to rush a release!

A quick fix is to emerge another package (emerge beep) so the last emerged package is something without ++ in the packagename.

About 3-way merging with Meld: I personally use xxdiff and vimdiff, but I think in Meld you have to click on the arrows to move blocks of text from one file to the other. The bad thing about the graphical 3-way diff tools is that most don't support intuitive manual editing. Xxdiff is an exception, I think it opens vim in the background, but I never even noticed that... usually it's enough to simply click on the colored sections in xxdiff.

If you don't want to use xxdiff, I would highly recommend vimdiff. Sure, it can't do 3-way merges but it does work with or without X and it allows you to edit the lines with regular vi-commands. So when you've mastered the vimdiff commands it's easy to update in any situation, even during installation on new systems when X is not available yet, on non-X servers or when the GUI is not available due to problems.

----------

## joyping

 *Quote:*   

> The error will only occur when the last packages that was merged contains ++ in the name. 

 

yes, you are right. the error is gone.

 *Quote:*   

> but I think in Meld you have to click on the arrows to move blocks of text from one file to the other.

 

i think i understand the interface of meld. even manual editing seems to work and with 2way-merges everything is fine. 

the problem with 3way-merges is, that regardles what i do, for example modifying the middle coloumn, saving it, after quitting meld cfg-update tells me that the update has been cancled. i tried altering all of the three files (and saving it), it makes no difference.

what i still don't understand when does cfg-update decide to do a 3way merge and why is it usefull since it could easier be done with a 2way diff.

i'll try xdiff and the others though to see if they behave different.

thanks for your answer...

----------

## xentric

 *Quote:*   

> The problem with 3way-merges is, that regardles what i do, for example modifying the middle coloumn, saving it, after quitting meld cfg-update tells me that the update has been cancled. i tried altering all of the three files (and saving it), it makes no difference.

 

I'll do some testing with Meld this weekend...

There are two ways to finish an update:

First method is to save the merged result as foo.merged, cfg-update will look for that file as soon as you exit the mergetool. I believe it even checks if the file is empty or not before deciding to complete or cancel the update. (I have to check the code to be sure)

Second method is to save the results over the original configfile, so if cfg-update doesn't find a foo.merged file it will check if the original foo file has been modified. If the file is not the same as it was before the update, it will conclude that you've saved your changes in the original file and it will complete the update by removing the ._cfg0000_foo file and permanently storing the backups.

These two methods are used by default because not all supported tools can save the results as foo.merged. So don't save the changes in the ._cfg0000_foo file, cfg-update will not detect it and it will cancel the update because it sees no changes.

 *Quote:*   

> what i still don't understand when does cfg-update decide to do a 3way merge and why is it usefull since it could easier be done with a 2way diff.
> 
> i'll try xdiff and the others though to see if they behave different.

 The 3-way merge is split into two stages. If cfg-update finds backups of a previous update, it can use those files to automatically determine what changes the devs have made in the new ._cfg0000_foo file and which changes (non-default settings) are made by you in the original file. As long as the devs haven't changed the same lines, cfg-update (by using diff3) can merge the changes so that both the new options/lines and your custom settings end up in the merged result.

If however, you and the devs have changed the same lines differently, a "merge-conflict" occurs. That's when cfg-update decides that you need to manually solve the merge-conflict. If it loads the three files (your_file, the_original_file, the_devs_update) in a GUI mergetool with 3-way merging support, and the non-conflicting lines will already be selected for you. You only have to solve the conflicts manually. xxdiff does this very nicely, don't know if Meld already selects the non-conflicting changes for you.

Ofcourse you can always disable the manual 3-way merge if you rather do this in 2-way merge mode...

Just read the extra info about the 5 stages in /etc/cfg-update.conf and disable the manual 3-way merge stage.

You can leave the automatic 3-way merge stage enabled, because if a merge-conflict occurs, cfg-update will resume the update in the manual 2-way stage.

 *Quote:*   

> thanks for your answer...

 You're welcome, thank you for giving me useful feedback!   :Very Happy: 

----------

## guid0

Gave tool xentric!

I am trying out some mass regeneration for testing a piece of flawed hardware and

i was wondering, is it possible to simulate the -5 option for emerge from the commandline?

I have been trying with

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

but without much luck.

Anyone?guid0.

----------

## devsk

 *Quote:*   

> Devsk is right, I should release 1.8.0-r4 soon  

 xentric, I am going to physically find you at the end of the (comcast?) cable and clobber you with jet li kicks....where is my r4 release, man?....  :Laughing: 

----------

## ppurka

 *devsk wrote:*   

>  *Quote:*   Devsk is right, I should release 1.8.0-r4 soon   xentric, I am going to physically find you at the end of the (comcast?) cable and clobber you with jet li kicks....where is my r4 release, man?.... 

 Yeah!  That's the spirit man!  BTW, you got the internet all wrong,- it is all tubes, tubes.

----------

## xentric

 *devsk wrote:*   

>  *Quote:*   Devsk is right, I should release 1.8.0-r4 soon   xentric, I am going to physically find you at the end of the (comcast?) cable and clobber you with jet li kicks....where is my r4 release, man?.... 

 

Oh oh, now I'm in trouble...    :Shocked: 

I'm gonna tell you straight up, my job is really hectic at the moment and my primary focus is on a promotion to a new function before the end of the month. Besides that I just bought a house and I spend a lot of time on painting, and polishing up the place.

You'll have to be a bit patient, but I apologise for not committing to my previous statements that r4 was coming up!

The only thing I can say is, don't count on r4 before the end of january. Only serious bugs will make me shift my priorities.

----------

## devsk

take it easy buddy...   :Smile: 

I was wondering if we could quickly include the changes for /var/log/portage (how you find the last emerge) and the awk thing we discussed before to speed it up a bit. We might forget otherwise....  :Razz:  do you think its a big change?

----------

## xentric

 *devsk wrote:*   

> take it easy buddy...  
> 
> I was wondering if we could quickly include the changes for /var/log/portage (how you find the last emerge) and the awk thing we discussed before to speed it up a bit. We might forget otherwise....  do you think its a big change?

 

Actually those fixes are working properly in my test version, it's the other changes that are still not 100%.

I think it's better for me to go back to version r3 and only add those fixes and leave the new stuff for later.

This approach doesn't need a lot of time, because the only thing remaining to be tested is emerging on a clean system.

That's the best I can do for now.

----------

## devsk

geart! So, is it possible to put those two fixes out as r4? Rest of the good stuff can probably wait for later. I will be able to test it for you.

----------

## xentric

 *devsk wrote:*   

> geart! So, is it possible to put those two fixes out as r4? Rest of the good stuff can probably wait for later. I will be able to test it for you.

 

Yep, that's what I meant to say, I'll make r4 have those fixes only and leave the rest for r5.

----------

## xentric

 *devsk wrote:*   

>  *Quote:*   Devsk is right, I should release 1.8.0-r4 soon   xentric, I am going to physically find you at the end of the (comcast?) cable and clobber you with jet li kicks....where is my r4 release, man?.... 

 

I couldn't sleep anymore, got nightmares about being chased by people kicking and screaming that I hadn't updated cfg-update in such a long time... I just had to do something about it   :Wink: 

Here you go guys... the ebuild has been submitted on bugzilla and should hit your local mirrors soon!

Edit: version 1.8.0-r4 had some minor flaws, fixing it at the moment, so probably r5 will be released.

Please report bugs in the Troubleshooting cfg-update thread.

----------

## Rick

 *xentric wrote:*   

> [21-jan-2007]
> 
> ... Also added vimdiff and gvimdiff support. 

 Great, that was the nr. 1 on my wishlist.

Goed gedaan! (well done, in dutch)

----------

## devsk

 *xentric wrote:*   

>  *devsk wrote:*    *Quote:*   Devsk is right, I should release 1.8.0-r4 soon   xentric, I am going to physically find you at the end of the (comcast?) cable and clobber you with jet li kicks....where is my r4 release, man?....  
> 
> I couldn't sleep anymore, got nightmares about being chased by people kicking and screaming that I hadn't updated cfg-update in such a long time... I just had to do something about it  
> 
> 

 hehe...extortion works....  :Very Happy:   :Wink:   :Laughing: 

thanks a bunch, for a faster and more robust cfg-update!

----------

## biggyL

Hi,

I'm using vimdiff which has no support with  3-way merge  :Sad: 

Is there any options for  CLI users to get  "3-way merge" function?

----------

## zxy

 *first post wrote:*   

> WARNING: If you use Paludis instead of portage you have to disable stage 2 in /etc/cfg-update.conf !!!
> 
> This issue will be fixed in version 1.8.0-r7

 

Thank you. Can't wait!!!

----------

## F.Ultra

 *Quote:*   

> 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
> ...

 Just some thoughts here, I do not know wheter this would work better or worse than how cfg-config currently works but anyways  :Smile: 

Instead of simply backing up the CONTENTS files before every emerge, couldn't we run a "find __DIR__ -type f | xargs md5sum" for each directory found in $CONFIG_PROTECT on initial install of cfg-update. This would build a file with the checksums of all the current config files.

Then when one runs cfg-update, after every config merge, cfg-update would be able to insert the current checksum of the newly merged file into this file thus keeping it updated.

With this scenario there would be no need for the /root/.bashrc hack and no need to run cfg-update --index before and after every emerge operation. A drawback would of course be if users changed the protected config files outside of cfg-update, but then the initial scan could be invoked manually by the user with say cfg-update --index.

----------

## xentric

 *F.Ultra wrote:*   

> Instead of simply backing up the CONTENTS files before every emerge, couldn't we run a "find __DIR__ -type f | xargs md5sum" for each directory found in $CONFIG_PROTECT on initial install of cfg-update. This would build a file with the checksums of all the current config files.

 But when you have done this and you have all the checksums, you still don't know if those files have been changed after they were installed. With that index you can only determine which files have been changed after the index creation. So on the very first run it's better to grab all the checksums from the CONTENTS file (as soon as all ._cfg0000_ files have been dealt with), with that index we can determine if a file has been changed after the file was installed. (and I bet that the current indexing method is faster)

 *Quote:*   

> Then when one runs cfg-update, after every config merge, cfg-update would be able to insert the current checksum of the newly merged file into this file thus keeping it updated.

 True, we can update the index with the checksum of the ._cfg0000_file as soon as the updating with cfg-update is completed. I agree that this is more efficient than rebuilding the index from CONTENTS files before every emerge action.

 *Quote:*   

> A drawback would of course be if users changed the protected config files outside of cfg-update, but then the initial scan could be invoked manually by the user with say cfg-update --index.

 Yes, if someone updates a configfile manually and removes the ._cfg0000_file, or also does updates with other tools like dispatch-conf/etc-update, cfg-update will not have the latest checksum in it's index. The result is that it will falsely show the file as being modified on the next update, resulting in a forced manual merge... This can be fixed by periodically grabbing the checksums from the CONTENTS files with "cfg-update --index", maybe with a daily cronjob.

I chose to use an alias to update the index right before the user uses the emerge command to install new packages. Because as soon as there are new ._cfg0000_files on the system, we can't update the index with the checksums from the CONTENTS files anymore. The current alias method catches 100% of all automatic updating opportunities...

Worst case scenario, of the alternative method, is that you'll miss out on a couple of automatic updating opportunities, forcing you to manually merge them with the GUI tool. But actually that's not such a bad trade-off if I can get rid of that ugly alias in /root/.bashrc!

I'll think about it for the next couple of days...

Thanks for bringing this up!

(However, I still think that a pre_emerge_session "hook" would be the best solution. I think that Paludis already has such hooks, but I've read more than once that Portage developers are not willing to implement these hooks into Portage)

----------

## F.Ultra

 *Quote:*   

> But when you have done this and you have all the checksums, you still don't know if those files have been changed after they were installed. ...

 Yes I did realise this after a while, the checksums are supposed to be for the files that portage wants to install and not the checksum of the files currently installed since they can have been modified by the user  :Embarassed: 

To march on to another topic  :Smile:  it would be great if one could have the full effect of the automatic updates from the beginning so I am exploring ways to create the backups needed for the 3-way merger. As I see, this could be done in two ways:

Way #1 is the simple one, here we only have to scan the protected directories and compare each files checksum with the content of the CONTENTS file. If they match then we have not modified the file since it was installed and we could copy it to ._new-cfg_foo as backup. This would enable us to get the full benefits of cfg-update if we modify the file later.

The remaining files have been modified by the user so here we have to extract the files from the tarballs (Way #2). But this is extremely more difficult. One can use equery belongs -e foo to find which package owns the file. Then ebuild /usr/portage/xxx-yyy/foo/foo-a.b-r2 unpack to unpack the tarball into /var/lib/portage/xxx-yyy/foo/work/ where we then can scan for the file.

A problem here can be that the file can have a different name in the tarball than in the protected place, it is quite common that it is named example.config or similair in the tarball and gets renamed by the Makefile. So perhaps we have to simply check each file against the CONTENTS checksum for the file we are looking for.

A secondary problem are files that are created at install or which are modified at install. They would however not match the checksum since the checksum is of the file that is installed after creation and modification (at least that is what I think) so the only drawback that we would encounter here is that we would have no way to create the backup file. And this is the main reason for performing way #1 first since there is chance that these files have not been modified by the user and such would be catched by way #1!

One thing with Way #2 is that it would take a very long time due to the amount of work that equery has to do, but then this only have to be done once on the initial install of cfg-update since cfg-update will automatically create the backups as new programs are installed.

 *Quote:*   

> However, I still think that a pre_emerge_session "hook" would be the best solution. I think that Paludis already has such hooks

 I agree completely with you, and I have plans to switch to Paludis anyways  :Smile:  My main interests with both Paludis and cfg-update is to enable comfortable maintenance of 100+ Gentoo servers and cfg-update is a real lifesaver in this area due to the many ways it really tries to make the updates automatic. I am also exploring ways to enable automatic updates with the help of cfg-update between machines, that is if I have to manually merge one file on one machine it would be possible for the other machines to perform the same changes on their file thus removing the need for performing manual updater on each machine. But more on that later  :Smile: 

----------

## xentric

 *F.Ultra wrote:*   

> Way #1 is the simple one, here we only have to scan the protected directories and compare each files checksum with the content of the CONTENTS file. If they match then we have not modified the file since it was installed and we could copy it to ._new-cfg_foo as backup. This would enable us to get the full benefits of cfg-update if we modify the file later.

 I could simply include a new option --create-ancestors that does this. That's a good one!

Way #2 has too many issues as you already pointed out. 

 *Quote:*   

> My main interests with both Paludis and cfg-update is to enable comfortable maintenance of 100+ Gentoo servers and cfg-update is a real lifesaver in this area due to the many ways it really tries to make the updates automatic. I am also exploring ways to enable automatic updates with the help of cfg-update between machines, that is if I have to manually merge one file on one machine it would be possible for the other machines to perform the same changes on their file thus removing the need for performing manual updater on each machine. But more on that later 

 

Actually I already have been thinking about this "taking care of updates on remote hosts"...

I think SSHFS and FUSE would be our best option here. That would give us access to remote filesystems as if they were on the localhost itself.

The only changes to cfg-update would be an index-per-host (all stored on the localhost) and a /etc/cfg-update.hosts file that specifies which mountpoints to use for the remote systems  :Very Happy: 

I get your point, the next step would then be to figure out a way to replicate a manual update on other hosts where no system specific settings are needed... pfff, I need to think a bit longer on that one   :Shocked: 

I'm going to see if I can get SSHFS and FUSE to work... (will take a while considering my spare time!)

You've got some seriously good ideas, keep'em coming!

----------

## Devport

Your last post xentric reminded me of another thing that I think would be an improvement : Right now cfg-update stores all intermediate files in their original folder cluttering e.g. /etc with lots of ._old-cfg / ._new-cfg files - I think they don't belong there. Could those files be stored in their own folder ? The files could be stored in e.g. /var/lib/cfg-update. In that folder the subfolder-structure could be maintained so that cfg-update knows where they were, e.g. /var/lib/cfg-update/etc/init.d/._old-cfg. Furthermore that would make it more maintanable for users / admins as all those files can then be found at one place.

----------

## xentric

 *Devport wrote:*   

> Your last post xentric reminded me of another thing that I think would be an improvement : Right now cfg-update stores all intermediate files in their original folder cluttering e.g. /etc with lots of ._old-cfg / ._new-cfg files - I think they don't belong there. Could those files be stored in their own folder ? The files could be stored in e.g. /var/lib/cfg-update. In that folder the subfolder-structure could be maintained so that cfg-update knows where they were, e.g. /var/lib/cfg-update/etc/init.d/._old-cfg.

 Yes the current way of storing the backups in the original directories isn't the most elegant solution. I have always told myself (to avoid having to change this = lame excuse, I know  :Wink: ) that it was just easier for a user if the backupfiles are in the same directory as the current configfile, and they are "hidden" dot-files anyway.

This should be the first thing to change because many more people have requested this...

It's on my TODO-list now   :Smile: 

Thanks!

----------

## F.Ultra

 *Quote:*   

> I think SSHFS and FUSE would be our best option here. That would give us access to remote filesystems as if they were on the localhost itself. 

 I like this! The traditional route taken by portage & co is to expose the management server (for example the portage tree) via NFS and then the managed servers have cronjobs that connect to the management server in order to do their magic.

This requires two things:

#1 The management server has to be positioned in your network so the managed servers can contact it, more or less dictades a place in the DMZ or even externally.

#2 The managed servers has to have extra software installed, for example the cronjobs etc.

With your thoughts about using SSHFS the situation is reversed, aka the management server can be put into the safer network and we only have to allow it to acess the various networks where the managed servers are, and also the software that we use to manage the servers only have to be installed on the management server! (i.e cfg-update and say paludis only need to be installed on the management server)

Another implification is that the management can be performed when the admin says so and not when some remote cronjob are executed. And it is far easier to let the management server reach out to x number of remote serverns per run (in case we have 10000 servers we do not want to start 10000 parelell sessions) than it is to tune the timings of the remote crons.

----------

## xentric

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!

Have fun...

----------

## XenoTerraCide

great! excellent work. will be testing soon.

----------

## devsk

Awesome!! I think single location for backup, was the most waited fix. Thank you so much!

----------

## zxy

xentric good work on latest version, i tested it with paludis on two machines for now and it works without problems. 

Thanks and keep up the good work.

 :Very Happy: 

----------

## swimmer

Very well done xentric!

The single backup location solution is much more cleaner and nicer ... the transition to that went flawless - thanks for that!

Greetz

swimmer

PS: Are you playing Q3 from time to time?  :Wink: 

----------

## xentric

 *swimmer wrote:*   

> PS: Are you playing Q3 from time to time? 

 No, I finally have a new computer that can handle Q3 but I haven't played any games on it yet  :Wink: 

I'm just enjoying the fast compile times at the moment, plus I can finally run vmware at decent speeds!

----------

## swimmer

Eventually yesterday I found out that the xentric that is playing all the time on the xs4all Q3-server is not dutch but german  :Wink: 

I apologize  :Smile: 

Greetz

swimmer

----------

## creidiki

Just remembered to check this thread to see if paludis support was in, tried it, works great, excellent work  :Very Happy: 

Btw, is it possible to kill the warning about the alias?

----------

## ppurka

 *creidiki wrote:*   

> Btw, is it possible to kill the warning about the alias?

 Yeah. Do what it says! Remove the alias  :Wink: 

----------

## creidiki

O dear, I never even noticed it added that last time I tried cfg-update o.o

----------

## bdm

Not sure if this is a bug. But I did 10 files and they all seem to be screwed up.

Here's what I now get when I go into the console:

```
bash: /etc/bash/bashrc: line 48: syntax error near unexpected token `>>'

bash: /etc/bash/bashrc: line 48: `>>>>>>>>>>>>>>>>>>>> File 1'

dircolors: `/etc/DIR_COLORS':90: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':91: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:94: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':98: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':100: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:103: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':119: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':126: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:133: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':151: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':153: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:154: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':158: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':167: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:176: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':178: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':184: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:190: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':197: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':198: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:200: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':213: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':216: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:224: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':227: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':228: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: /etc/DIR_COLORS:230: invalid line;  missing second token

dircolors: `/etc/DIR_COLORS':232: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':240: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

dircolors: `/etc/DIR_COLORS':241: unrecognized keyword >>>>>>>>>>>>>>>>>>>>

bash: /etc/bash/bashrc: line 48: syntax error near unexpected token `>>'

bash: /etc/bash/bashrc: line 48: `>>>>>>>>>>>>>>>>>>>> File 1'

```

And each file I updated has a buncxh of File1 File2 >>>>> blah blah.

Any ideas?

----------

## xentric

 *bdm wrote:*   

> Any ideas?

 Can you post the complete and unedited contents of /etc/bash/bashrc?

----------

## XenoTerraCide

some thoughts... does the latest cfg-update scan just the config files for the package it's currenly on? if not would that be plausible? also I was wondering if the scan could be backgrounded... because _usually_ it would finish before any files would install.

----------

## xentric

 *XenoTerraCide wrote:*   

> some thoughts... does the latest cfg-update scan just the config files for the package it's currenly on? if not would that be plausible?

 This question makes me wonder how many seconds the index update takes on your machine?

It is possible, but is it worth the trouble of changing this?

 *Quote:*   

> also I was wondering if the scan could be backgrounded... because _usually_ it would finish before any files would install.

 I like the idea, but the _usually_ always worries me a bit   :Wink: 

If it doesn't finish before the first files are being installed, there's a possibility that the wrong checksums end up in the index. Worst case is that an unmodified file would show up as being modified... so you potentially miss out on automatic updates which is the whole point of using the index. The chances of this not-so-optimal situation increase when updating the index takes a long time.

That's why I want to know how long it takes on your system to update the index... 

(You can time it with "time cfg-update --force --index")

----------

## Rick

I'm getting this right now:

```
# time cfg-update --force --index

>>> cfg-update-1.8.2-r1: Creating checksum index...

cfg-update --force --index  1.66s user 1.33s system 15% cpu 19.506 total
```

Trying it for a second time naturally drops it to 2s.

Either way, I know enough ebuilds that finish well within 20 seconds so I have my doubts it would be safe. The only safe way to do it is threading it with a semaphore or something like that.

----------

## Devport

What about meta packages which dont install anything but may come with a configuration file - its probably possible that they would finish faster than the indexing.

----------

## Rick

Even without meta packages, most python packages are just download and unpack, most of the small ones are done within 5-10 seconds here.

----------

## XenoTerraCide

from running twice in a row 

```

slave1 ~ # time cfg-update --force --index

>>> cfg-update-1.8.2-r1: Creating checksum index...

real    0m16.891s

user    0m0.730s

sys     0m0.580s

slave1 ~ # time cfg-update --force --index

>>> cfg-update-1.8.2-r1: Creating checksum index...

real    0m1.220s

user    0m0.690s

sys     0m0.420s

```

 I'm just thinking of possible ways it could be improved... maybe it could create a lock file and if it wasn't finished by the time that portage was ready to write files portage would have to wait. btw, I've not seen so many meta packages that write config file. they are meta because all they do is pull in other packages.

----------

## xentric

 *Rick wrote:*   

> I'm getting this right now:
> 
> ```
> # time cfg-update --force --index
> 
> ...

 I get similar results, about 20 secs on a Pentium3 850Mhz.

I have changed the way the index is built because of 2 things:

1. There's a fixed limit on the number of files that can be handled in tools like grep (got bug report) so I had to change it and now it uses echo/xargs for creating the index.

2. cfg-update now supports updating of remote machines from a single location. The index used to be about 17Mb (on my machine), as it was a full dump of all checksums. The new version only stores the checksums of files in the protected directories, which is slower, but it results in a much smaller index of about 120Kb. The smaller size is needed for accessing the index file over a network connection...

The 20 secs indexing per package drops to about 1 second as soon as ._cfg0000_ files are found because that will make cfg-update skip the index update. So is the 20 secs really a problem?

However, I could add a variable that controls the indexing method: 

FAST_INDEXING = yes # (default) indexing will take about 6 secs but this index isn't usable for remote updating.

FAST_INDEXING = no # indexing will take about 20 secs and index can be used by a remote cfg-update session.

Until the next version is released, you can speed up the index with this change to /usr/bin/cfg-update

comment out line 730-733:

```
        for (my $i = 0; $i < @dir; ++$i) {

# The following command needs to use echo and xargs because cat and grep both have limitations on the number of...

            `echo $pkg_db/*/*/CONTENTS $debug | xargs grep "^obj $dir[$i]" | cut -d" " -f2-3 $debug >> $index_file`;

        }
```

and add an extra line under it, so it looks like this:

```
#        for (my $i = 0; $i < @dir; ++$i) {

# The following command needs to use echo and xargs because cat and grep both have limitations on the number of...

#            `echo $pkg_db/*/*/CONTENTS $debug | xargs grep "^obj $dir[$i]" | cut -d" " -f2-3 $debug >> $index_file`;

#        }

        `echo $pkg_db/*/*/CONTENTS $debug | xargs grep "^obj " | cut -d" " -f2-3 $debug >> $index_file`;
```

----------

## iBormuth

Hmm, vimdiff can show up to 4 files next to each other.

What do you think of the following?

```

--- /usr/bin/cfg-update   2007-07-10 17:58:07.000000000 +0200

+++ cfg-update   2007-07-10 17:56:56.000000000 +0200

@@ -793,7 +793,7 @@

         if ($opt_d >= 1) { print "$tab"."stage4 disabled...\n"; }

     }

 # Check if tool can handle manual 3-way merges...

-    if ($merge_tool =~ /\/xxdiff$|^xxdiff$|\/kdiff3$|^kdiff3$|\/meld$|^meld$|\/tkdiff$|^tkdiff$/) {

+    if ($merge_tool =~ /\/xxdiff$|^xxdiff$|\/kdiff3$|^kdiff3$|\/meld$|^meld$|\/tkdiff$|^tkdiff$|\/vimdiff$|^vimdiff$|\/gvimdiff$|^gvimdiff$/) {

         $tool_supports_3way = "yes";

         if ($opt_d >= 1) { print "$tab"."tool_supports_3way                = $tool_supports_3way\n"; }

     } else {

@@ -835,8 +835,10 @@

     if (($_[1] =~ /\/meld$|^meld$/         ) && ($threeway_update =~ "no" )) { $cmd = "$_[1] $file1 $file2 $debug"; }

     if (($_[1] =~ /\/tkdiff$|^tkdiff$/     ) && ($threeway_update =~ "yes")) { $cmd = "$_[1] $file1 $file2 -a $file4 -o $file5 $debug"; }

     if (($_[1] =~ /\/tkdiff$|^tkdiff$/     ) && ($threeway_update =~ "no" )) { $cmd = "$_[1] $file1 $file2 -o $file5 $debug"; }

-    if  ($_[1] =~ /\/vimdiff$|^vimdiff$/   )                                 { $cmd = "$_[1] -c 'saveas $file1' -c next -c 'setlocal nomodifiable readonly' -c prev $file1 $file2 --nofork $debug"; }

-    if  ($_[1] =~ /\/gvimdiff$|^gvimdiff$/ )                                 { $cmd = "$_[1] -c 'saveas $file1' -c next -c 'setlocal nomodifiable readonly' -c prev $file1 $file2 --nofork 2>\&1>/dev/null"; }

+    if (($_[1] =~ /\/vimdiff$|^vimdiff$/   ) && ($threeway_update =~ "yes")) { $cmd = "$_[1] $file1 $file2 $file4 +2b '+setlocal ma ro' +3b '+setlocal ma ro' +1b $debug"; }

+    if (($_[1] =~ /\/vimdiff$|^vimdiff$/   ) && ($threeway_update =~ "no" )) { $cmd = "$_[1] $file1 $file2 +2b '+setlocal ma ro' +1b $debug"; }

+    if (($_[1] =~ /\/gvimdiff$|^gvimdiff$/ ) && ($threeway_update =~ "yes")) { $cmd = "$_[1] $file1 $file2 $file4 +2b '+setlocal ma ro' +3b '+setlocal ma ro' +1b --nofork $debug"; }

+    if (($_[1] =~ /\/gvimdiff$|^gvimdiff$/ ) && ($threeway_update =~ "yes")) { $cmd = "$_[1] $file1 $file2 +2b '+setlocal ma ro' +1b --nofork $debug"; }

     if  ($_[1] =~ /\/gtkdiff$|^gtkdiff$/   )                                 { $cmd = "$_[1] -o $file5 $file1 $file2 $debug"; }

     if  ($_[1] =~ /\/imediff2$|^imediff2$/ )                                 { $cmd = "$_[1] -c -o $file5 $file1 $file2"; }

     if  ($_[1] =~ /\/sdiff$|^sdiff$/       )     

```

You merge to the first column.

Just type ':diffg 2' or ':diffg 3' to get the corresponding block from another column.

Type :wqa to quit (column 2+3 are readonly).

Did I miss anything?

----------

## bell

Hallo,

cfg-update rocks!

I have a future-Request for this great tool.

cfg-update should respect env-variables ROOT and PORTAGE_CONFIGROOT

Thats needed for update config files on mounted gentoo disks without chroot or on gentoo-crosscompiled targets.

Current i dont know any way for updating config files on my crossdev/emerge-crosscompiled ARM target.

 *Quote:*   

> 
> 
> man emerge
> 
> ..
> ...

 

----------

## xentric

 *bell wrote:*   

> Current i dont know any way for updating config files on my crossdev/emerge-crosscompiled ARM target.

 cfg-update supports updating multiple (remote)hosts from a single location. As long as the complete system of the host is available via a mountpoint, the backup directory is in the same location behind the mountpoint and it has an indexfile in the same location behind the mountpoint, you should be OK.

So if the BACKUP_PATH on your localhost is /var/lib/cfg-update/backups, just create the directory /your_mount_point/var/lib/cfg-update/backups.

Now comes the -I'm not sure this will work- part, cfg-update also expects an indexfile on the remote host, but because you probably update that host with Portage from your localhost you can try copying or soft-linking the /var/lib/cfg-update/checksum.index file from your localhost to /your_mount_point/var/lib/cfg-update/checksum.index

I think that if you then add your mountpoint (just leave mount_cmd and unmount_cmd empty) to the bottom of /etc/cfg-update.hosts it could work...

cfg-update --check = check if all hosts (mountpoints) are ready for updating

cfg-update -l = list the config updates on the localhost

cfg-update -u = update the config updates on the localhost

cfg-update -lh 1 = list the config updates on the first hosts

cfg-update -uh 1 = update the config updates on the first hosts

cfg-update -lh = list the config updates on all hosts

cfg-update -uh = update the config updates on all hosts

(I'm not sure if the indexfile on your localhost also contains MD5sums for the files on your mounted ARM system... If it doesn't contain the checksums from your ARM machine cfg-update will mark all updates as modified files, thus forcing you to update manually. But as soon as you update a file for a second time cfg-update will at least try the automatic 3-way merge with the backup of the first previous update. So eventually cfg-update will update more files automatically on your ARM machine even though it cannot use the checksum-index!)

Please let me know if this works... or if you have any questions!

----------

## bell

Thanks, it works "as mounted host" with cfg-update -[lu]h 1.

It shows the "Error: host not mounted", but i can update the config files.

But for uniformity with portage is nice to support ROOT (=mountpoint) and PORTAGE_CONFIGROOT = (Path to cfg-update config files without /etc/* at end).

PORTAGE_CONFIGROOT is from environment

ROOT is from environment or if not set from fgrep ROOT= $PORTAGE_CONFIGROOT/etc/make.conf

----------

## XenoTerraCide

FEATURE REQUEST.

when cfg-update detects 

```

* YOU ARE ABOUT TO UPDATE A MODIFIED FILE WHICH PROBABLY CONTAINS

* CUSTOM SETTINGS. YOU ARE FORCED TO UPDATE MANUALLY!

  Press [y] - to merge the current file and the ._cfg0000_* file with vimdiff

  Press [s] - to skip this update (to investigate first, and try again later)

  Press [q] - to quit cfg-update immediately

```

add these to the initial list. I don't need to check my files when I've just done a re-merge. (e.g. the program should treat me like I know what I'm doing).

```

  Press [1] - to replace the current file with the ._cfg0000_* file

  Press [2] - to keep the current file and remove the ._cfg0000_* file

```

----------

## xentric

Ok thanks, added it to my TODO-list...

----------

## XenoTerraCide

is cfg-update on a vcs anywhere?

----------

## xentric

******************************************************************************

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 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 out there would just 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.

Drop me an e-mail on the same address if you're interested in adopting cfg-update.

Regards,

Stephan van Boven

******************************************************************************

----------

## SpineBuster

Hi guys!

Found a bug. 

When I log into my non-X system (with ssh+Xforwarding), cfg-update won't start the GUI diffs although I'm locally running an X server.

I looked into the script and it uses "xhost" to check if an X server is running but of course this file doesn't even exist on the server, so it never tries to start e.g. xxdiff.

regards

Matthias

----------

## xentric

 *SpineBuster wrote:*   

> When I log into my non-X system (with ssh+Xforwarding), cfg-update won't start the GUI diffs although I'm locally running an X server.
> 
> I looked into the script and it uses "xhost" to check if an X server is running but of course this file doesn't even exist on the server, so it never tries to start e.g. xxdiff.

 

Hi Matthias,

Thanks for reporting this bug.

I'll probably put in an extra commandline switch to override the xhosts check, unless you can provide me with a better solution.

I still have to release the new version so I'll try to fix this issue before releasing it.

But releasing could take a while as I do not have a lot of free time to tinker with the script.

In the meanwhile, read /etc/cfg-update.hosts and try following the instructions to set up your non-X system as a remote host.

That method will enable you to update your non-X system(s) from your X enabled system as if you were updating locally.

Hope this helps   :Very Happy: 

----------

## TheHistorian

 *SpineBuster wrote:*   

> Hi guys!
> 
> Found a bug. 
> 
> When I log into my non-X system (with ssh+Xforwarding), cfg-update won't start the GUI diffs although I'm locally running an X server.
> ...

 

I just ran across this bug and came searching the forums for a solution.  For me, I just emerged xhost, even on the non-X systems.  It has a couple X library dependencies, but it doesn't drag in all of X.

So I'd recommend making xhost a dependency of cfg-update.

----------

## rich0

FYI - if anybody else is still using this I'm going to go ahead and keep it around.  I copied the source to github and if anybody has any suggestions/etc let me know.  Patches of course would be more appreciated still...   :Smile: 

----------

## ppurka

 *rich0 wrote:*   

> FYI - if anybody else is still using this I'm going to go ahead and keep it around.  I copied the source to github and if anybody has any suggestions/etc let me know.  Patches of course would be more appreciated still...  

 Yeah. keep it around. Works flawlessly here. And, thanks for taking over maintainership  :Smile: 

----------

## ddriver

I'd like you to keep this going if you can. I've been using it for years after trying the other tools and finding them lacking.

I have a small suggestion for an improvement if you're interested.

----------

## rich0

 *ddriver wrote:*   

> I'd like you to keep this going if you can. I've been using it for years after trying the other tools and finding them lacking.
> 
> I have a small suggestion for an improvement if you're interested.

 

Always interested in suggestions.  I'm not the world's greatest perl guru, so I can't promise the world here...

----------

## ddriver

 *rich0 wrote:*   

> 
> 
> Always interested in suggestions.  I'm not the world's greatest perl guru, so I can't promise the world here...

 

OK here goes.

I would like the replace/keep options to be shown earlier in the dialogue.

e.g. I see the following and in most cases I already know that I want to keep the current file or that I want to overwrite it with the ._cfg0000_* file:

```
* YOU ARE ABOUT TO UPDATE A CUSTOM FILE. YOU SHOULD ASK YOURSELF

* WHERE DOES IT COME FROM AND WHAT HAPPENDS WHEN YOU REPLACE IT?

* PORTAGE DID NOT INSTALL THE CURRENT FILE, MOST LIKELY IT HAS BEEN

* CREATED AFTER INSTALLATION AND IT MAY CONTAIN CUSTOM SETTINGS.

  Press [y] - to merge the current file and the ._cfg0000_* file with vimdiff

  Press [s] - to skip this update (to investigate first, and try again later)

  Press [q] - to quit cfg-update immediately
```

I then have to go through the steps of closing down three successive vi sessions before I get to the stage where I get these options:

```
  Press [1] - to replace the current file with the ._cfg0000_* file

  Press [2] - to keep the current file and remove the ._cfg0000_* file
```

so it would be wonderful to have these two options in the original menu.

While you're at it, you could rename these options r and k for replace and keep. I always have to read carefully to make sure I pick the right one.

Does this make sense?

----------

## ddriver

I've been meaning to dig out the source code for ages and make these changes myself. I'm fairly experienced with Perl. Just never got round to it.

----------

## rich0

 *ddriver wrote:*   

> 
> 
> Does this make sense?

 

That makes sense to me, and without looking at the code it SEEMS like it should be straightforward to implement:

https://github.com/rich0/cfg-update/issues/1

----------

## ppurka

Well, then the option for restore/keep should not be removed from the old stage. This is because, it often happens that we view the diff first and then decide that the changes in the new file are not what we want.

----------

## ddriver

 *ppurka wrote:*   

> Well, then the option for restore/keep should not be removed from the old stage. This is because, it often happens that we view the diff first and then decide that the changes in the new file are not what we want.

 

Agreed. In which case, can we have these options in both places?

----------

## rich0

 *ddriver wrote:*   

>  *ppurka wrote:*   Well, then the option for restore/keep should not be removed from the old stage. This is because, it often happens that we view the diff first and then decide that the changes in the new file are not what we want. 
> 
> Agreed. In which case, can we have these options in both places?

 

That was my thinking as well.

----------

## devsk

I am so glad this piece of code is seeing an owner. This is one of the very best tools for portage. I have been using it for years and have it installed everywhere!

----------

## rich0

I moved the update options earlier.  You can download it at:

https://raw.github.com/rich0/cfg-update/master/cfg-update

I'm interested in any testing feedback.  You can just drop that one file in over /usr/bin/cfg-update if you're otherwise on the latest version in portage.

Since the auto-update feature is working so well I'm finding it tricky to test.   :Smile: 

If feedback is generally positive I'll put that in the next release.

----------

## ppurka

 *rich0 wrote:*   

> I moved the update options earlier.  You can download it at:
> 
> https://raw.github.com/rich0/cfg-update/master/cfg-update
> 
> I'm interested in any testing feedback.  You can just drop that one file in over /usr/bin/cfg-update if you're otherwise on the latest version in portage.
> ...

 Thanks! It works!

An easy way to test this:

* make sure /etc/portage is a config protected directory

* run emerge -a --autounmask-write <some package in testing that is not keyworded>

* run cfg-update -u (and you should get that option, and it works)

----------

## rich0

Yup, it is working in my other tests as well.

So, those who are dying for this feel free to use it.  It will go into portage once I get beediff support coded into it and tested.  I'm trying not to bombard people with a version bump every other day...

----------

## rich0

Just a heads-up to cfg-update users/followers that I plan to stabilize 1.8.7 in about a week.  If you're already using ~arch then you won't see any changes.

Key improvements are a bunch of Paludis improvements from Marc-Antoine Perennou, and implementing the option to just replace or drop files without having to view them (very useful with the new portage auto-keyword/etc feature).  

I've been running with it without issue for a month, but if anybody spots a problem in the next week be sure to file a bug.

----------

## xentric

Hi rich0,

Good to see that you are taking care of cfg-update, thanks!

I just want to give you a quick tip about testing the cfg-update functionality after code changes:

The cfg-update tarball contains a small tarball named test.tgz. If you extract that tarball to /etc you get some test-files in /etc/test. There is a testfile for every type of update that can occur. After extracting the tarball to /etc just run the script /etc/test/prepare_cfg-update_test. This script manipulates your index file so that cfg-update thinks that these tests are real updates that need to be done.

Then simply run cfg-update -l to see the tests that are ready to be run, followed by cfg-update -u to run those tests...

This way you can easily test: 

- if the script handles the various types of updates in the correct stage

- if the script flow is still OK and menus have the right options to choose from

- if it launches the GUI or CLI merge-tool properly

- by viewing the contents of the test-files after the update you can verify if the update itself was done correctly by either the script or the GUI or CLI merge-tool

Sorry for not being able to continue to support the package myself!

Keep up the good work  :Smile: 

PS. I really regret only one thing; adding the multi-remote-host-update functionality!

      Does anyone actually use that? I guess it only added an extra layer of unnecessary complexity. Sorry for that!

----------

## devsk

Sorry for resurrecting a 4 year old thread but this was only place where I could find. First of all, huge fan of cfg-update and have been using it all my gentoo life from the beginning of this beautiful utility.

I am building a very small custom OVA for an embedded product using ROOT functionality of the portage (you set ROOT=/home/myova, and emerge installs stuff in /home/myova). My major gripe is the unavailability of cfg-update in that context to manage configuration updates. I can chroot into this ROOT but its very minimal. There is no perl and no X.

I was wondering if cfg-update could be extended to allow to work on an arbitrary root instead of only on "/". Has anybody done any research/work on it?

----------

## rich0

 *devsk wrote:*   

> I am building a very small custom OVA for an embedded product using ROOT functionality of the portage (you set ROOT=/home/myova, and emerge installs stuff in /home/myova). My major gripe is the unavailability of cfg-update in that context to manage configuration updates. I can chroot into this ROOT but its very minimal. There is no perl and no X.
> 
> I was wondering if cfg-update could be extended to allow to work on an arbitrary root instead of only on "/". Has anybody done any research/work on it?

 

Just noticed your thread.  I'm sure it could be done -cfg-update actually has a ton of code for managing remote hosts already.  I'd probably start looking at that first to see if it can be adapted for your purpose.  I'll probably accept patches if you get this to work.

This would actually be handy for managing things like containers.  I end up installing X all over the place just so that I can use meld to merge my changes.

----------

