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..._________________When all else fails, read the manual...
Registered Linux User #340626

# 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"

# 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"

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

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*_________________When all else fails, read the manual...
Registered Linux User #340626

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

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:

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:

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!)_________________When all else fails, read the manual...
Registered Linux User #340626

Last edited by xentric on Thu Feb 12, 2004 4:44 pm; edited 3 times in total

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

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

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

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._________________When all else fails, read the manual...
Registered Linux User #340626

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

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

/root/.bashrc [found] edit this file as described in the man page!
/root/.bash_profile [missing...copied]
/root/.Xdefaults [found] edit this file as described in the man page!
________________________________________________________________________________

expresso mark # cfg-update -u

No (._cfg[0-9]{4}_*) files found...

btw, i did log out and back in just to make sure the missing bash_profile was getting sourced if needed. same results...

/root/.bashrc [found] edit this file as described in the man page!
/root/.bash_profile [found]
/root/.Xdefaults [found] edit this file as described in the man page!
________________________________________________________________________________

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.

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._________________When all else fails, read the manual...
Registered Linux User #340626