app-portage/cfg-update - installation instructions

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

Code: Select all

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

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

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)

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

You can temporarily switch off the alias by typing:

Code: Select all

cfg-update --off
source /etc/profile

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

Code: Select all

cfg-update --on
source /etc/profile

[yuza]

Thanks for the trick!

[micron]

It's really a great job xentric, you've saved me!
My etc-config segfaulted and I wasn't able to update my conf files, but now...
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.

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]

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]

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

I'll keep my finger crossed!!

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

Code: Select all

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

Code: Select all

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

cfg-update 1.6 : Building checksum index... (takes a few seconds)  done!
________________________________________________________________________________

Sun Feb 22 19:54:59 JST 2004

Original version:

Code: Select all

date; cfg-update --index; date
Sun Feb 22 19:56:04 JST 2004
Use of uninitialized value in pattern match (m//) at /usr/bin/cfg-update line 271.
________________________________________________________________________________

cfg-update 1.6 : Building checksum index... (takes a few seconds)  done!
________________________________________________________________________________

Sun Feb 22 20:01:54 JST 2004

I believe that cfg-update could benefit from removing the pipe to grep in all locations where there is pipe to awk as well. I.e. something like the following:

Code: Select all

--- /var/tmp/portage/cfg-update-1.6/work/cfg-update-1.6/cfg-update.pl   2004-02-13 02:20:47.000000000 +0900
+++ /usr/lib/cfg-update/cfg-update.pl   2004-02-22 20:08:20.993712690 +0900
@@ -239,12 +239,12 @@
 }
 
 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{
     for (my $i = 0; $i < @dir; ++$i) {
-        `cat /var/db/pkg/*/*/CONTENTS | grep '^obj $dir[$i]' | awk '{ print \$2"  "\$3 }' >>$index`;
+        `cat /var/db/pkg/*/*/CONTENTS | awk '/^obj $dir[$i]/ { print \$2"  "\$3 }' >>$index`;
     }
 }
 
@@ -279,7 +279,7 @@
        if (-f "$index") {
         my $md5sum_file = `md5sum $file1 2>/dev/null | awk '{ print \$1 }' 2>/dev/null`;
         chomp $md5sum_file;
-        my $md5sum_index = `cat $index | grep $file1 | awk '{ print \$2 }' 2>/dev/null`;
+        my $md5sum_index = `cat $index | awk '/$file1/ { print \$2 }' 2>/dev/null`;
         chomp $md5sum_index;
                if ($md5sum_index =~ /.+/) {
             if ($md5sum_index !~ $md5sum_file) {

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

Code: Select all

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

cfg-update 1.6 : Building checksum index... (takes a few seconds)  done!
________________________________________________________________________________


real    0m12.558s
user    0m1.461s
sys     0m0.737s

I don't know how many packages you have on your system, what filesystem you use or what
other factors can make the index-building so slow... The above is a test on my machine, a
Pentium3 850Mhz with Reiserfs. But I didn't notice significant speed changes on my old
Pentium1 233Mhz system.

I don't have time right now to test your patch, but if I look at your tests I think it will make
it into the next ebuild if it's faster on my machine too. Please remember that this is a small
script that has kinda grown out of proportion. It's a hack to make a safer etc-update, but
right now I have very limited time to spend on this project... sorry for that I'm doing what
I can to make it usable and keep it usable!

[St_Andrew]

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

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

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]

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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

Code: Select all

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:

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.
If no developer cares about them, they tend not to make it into the tree.
For right or wrong, that's how things work today.

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?):
http://bugs.gentoo.org/show_bug.cgi?id=32728