app-portage/cfg-update - installation instructions

Message

raptor · Post by **raptor** » Sun Jan 11, 2004 5:04 pm

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

charlieg · Post by **charlieg** » Mon Jan 12, 2004 1:56 am

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

xentric · Post by **xentric** » Mon Jan 12, 2004 12:17 pm

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

Code: Select all

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 · Post by **xentric** » Mon Jan 12, 2004 1:02 pm

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

rberry88 · Post by **rberry88** » Fri Jan 16, 2004 12:28 am

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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 · Post by **OrezzerO** » Fri Jan 16, 2004 6:57 pm

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 · Post by **xentric** » Sun Jan 25, 2004 11:09 pm

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 · Post by **meowsqueak** » Mon Feb 09, 2004 8:49 pm

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 ... 1.5.tar.gz

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

yuza · Post by **yuza** » Mon Feb 09, 2004 10:47 pm

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 · Post by **meowsqueak** » Mon Feb 09, 2004 10:55 pm

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

xentric · Post by **xentric** » Tue Feb 10, 2004 4:07 pm

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

xentric · Post by **xentric** » Tue Feb 10, 2004 7:53 pm

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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 · Post by **meowsqueak** » Tue Feb 10, 2004 8:27 pm

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

xentric · Post by **xentric** » Tue Feb 10, 2004 8:55 pm

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 · Post by **xentric** » Tue Feb 10, 2004 10:50 pm

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 · Post by **yuza** » Tue Feb 10, 2004 10:54 pm

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 · Post by **mlybarger** » Wed Feb 11, 2004 3:38 am

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.

Code: Select all

bash-2.05b$ su -l
Password:
expresso mark # cfg-update --check
________________________________________________________________________________

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

pross · Post by **pross** » Wed Feb 11, 2004 10:07 pm

same problem here

* GNU info directory index is up-to-date.
* IMPORTANT: 23 config files in /etc need updating.
* IMPORTANT: 2 config files in /usr/X11R6/lib/X11/xkb need updating.
* IMPORTANT: 1 config files in /usr/kde/3.2/share/config need updating.

Gentoo pross # cfg-update -l
No (._cfg[0-9]{4}_*) files found...

Gentoo pross # cfg-update --check
________________________________________________________________________________

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

infamousmrsatan · Post by **infamousmrsatan** » Thu Feb 12, 2004 12:47 pm

me too. any ideas? I have 118 config files to clean up, and do NOT want to use etc-update

But cfg-update doesn't see any of them.

mlybarger · Post by **mlybarger** » Thu Feb 12, 2004 12:59 pm

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 · Post by **infamousmrsatan** » Thu Feb 12, 2004 2:52 pm

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 · Post by **xentric** » Thu Feb 12, 2004 4:52 pm

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 · Post by **pross** » Thu Feb 12, 2004 7:46 pm

works now

whiskeypriest · Post by **whiskeypriest** » Fri Feb 13, 2004 5:07 pm

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 · Post by **infamousmrsatan** » Sat Feb 14, 2004 6:34 am

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

app-portage/cfg-update - installation instructions

what about gtk+

No X!

Re: No X!