| View previous topic :: View next topic |
| Author |
Message |
zebrapad
Tux's lil' helper
Joined: 12 Jul 2004
Posts: 83
Location: Leuven, Belgium
|
 Posted: Sat Jan 15, 2005 11:24 am Post subject: |
 |
|
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
[q]uit quit immediately |
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
[n]o skip this file and go to the next config file
[c]opy copy the new file
[a]uto automatically merge the file
[q]uit quit immediately
|
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 
_________________
specs that may be relevant to my post: AMD Phenom II X3 720, NVidia GTX260, Gentoo Linux 64bit 2008.0, GCC 4.4.1, -march=amdfam10 -O2 -pipe |
|
| Back to top |
|
 |
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sat Jan 15, 2005 6:52 pm Post subject: |
|
|
| zebrapad wrote: | | The script could add some option to copy the new file... |
Well, these are your options:
| Code: | [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...
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Mon Jan 24, 2005 5:30 pm Post subject: |
|
|
Version 1.7 released...
Please test it and report any bugs in this thread: Troubleshooting cfg-update...
It can use meld now 
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Jan 26, 2005 7:47 am Post subject: |
|
|
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:
| Code: | | gnome? ( >=dev-util-meld-0.9 )" |
to: | Code: | | gnome? ( >=dev-util/meld-0.9 )" |
Otherwise you can encounter this error:
emerge: there are no ebuilds to satisfy ">=dev-util-meld-0.9".
| Code: | 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. |
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
ccduffy
n00b
Joined: 05 Feb 2005
Posts: 3
Location: Austin, TX
|
| Posted: Sat Feb 05, 2005 7:19 am Post subject: diff3 merging support? |
|
|
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). |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sat Feb 05, 2005 8:17 am Post subject: Re: diff3 merging support? |
|
|
| 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.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sun Feb 06, 2005 5:19 pm Post subject: |
|
|
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) | Code: | #header v1.0 - dec 2003
param1=customized_value
param2=customized_value
param3=default_value |
/etc/example (This is the current configuration file) | Code: | #header v1.1 - aug 2004
param1=customized_value
param2=customized_value
param3=default_value |
/etc/._cfg0000_example (This is the newest version available): | Code: | #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: | Code: | 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) | Code: | <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: | Code: | 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) | Code: | <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? 
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
ccduffy
n00b
Joined: 05 Feb 2005
Posts: 3
Location: Austin, TX
|
| Posted: Sun Feb 06, 2005 10:33 pm Post subject: 3-way diffing |
|
|
| 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
or newly included lines. You can't have both due to the fundamental design of
the 3-way diff. Or am I overlooking something? |
Use the old original (non-modified) file as ancestor.
foo.conf.base:
| Code: | #header v1.0
param1=default_value
param2=default_value
param3=default_value |
foo.conf:
| Code: | #header v1.0
param1=default_value
param2=modified_value
param3=modified_value |
foo.conf.new:
| Code: | #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:
| Code: | 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:
| Code: | #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. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sun Feb 06, 2005 11:16 pm Post subject: |
|
|
Ahh... now I get it
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 !
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
cmuench
Tux's lil' helper
Joined: 04 Jan 2005
Posts: 110
|
| Posted: Mon Feb 07, 2005 9:25 pm Post subject: |
|
|
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] |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Tue Feb 08, 2005 4:52 pm Post subject: |
|
|
| 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.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
cmuench
Tux's lil' helper
Joined: 04 Jan 2005
Posts: 110
|
| Posted: Tue Feb 08, 2005 9:23 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
radfoj
Guru
Joined: 31 Dec 2004
Posts: 490
Location: Tísek, Czech Republic
|
| Posted: Tue Feb 08, 2005 9:40 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
ccduffy
n00b
Joined: 05 Feb 2005
Posts: 3
Location: Austin, TX
|
| Posted: Fri Feb 18, 2005 10:38 pm Post subject: Release schedule? Public RCS access? |
|
|
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? |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sat Feb 19, 2005 3:19 am Post subject: Re: Release schedule? Public RCS access? |
|
|
| 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 OK !?
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Apr 06, 2005 8:38 pm Post subject: Re: GUI alternative for etc-update -> cfg-update v1.7 |
|
|
wrong button... oops
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
Freejack00
n00b
Joined: 02 Aug 2004
Posts: 22
|
| Posted: Tue Apr 12, 2005 7:43 pm Post subject: |
|
|
| Nice program and idea, would be nice to have a link to the program. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Wed Apr 13, 2005 10:25 pm Post subject: |
|
|
| 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...
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
infamousmrsatan
Apprentice
Joined: 08 Jan 2004
Posts: 201
Location: California
|
| Posted: Thu Jun 09, 2005 11:17 am Post subject: |
|
|
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
_________________
Registered Linux User 344425
Join the adopt an unanswered post initiative today!
Por favor, corrija mi espanol! |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Thu Jun 09, 2005 4:54 pm Post subject: |
|
|
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
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
[UK]Superdude
Tux's lil' helper
Joined: 22 Jul 2002
Posts: 149
Location: Adelaide, Australia
|
| Posted: Sat Jun 11, 2005 8:05 am Post subject: |
|
|
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 ) 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 |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sat Jun 11, 2005 12:45 pm Post subject: |
|
|
| [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
(like me ) 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 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 !
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
jsgaarde
n00b
Joined: 24 Mar 2005
Posts: 9
|
| Posted: Sun Jun 12, 2005 11:36 am Post subject: |
|
|
I'm trying to run cfg-update, but:
First run
| Code: | 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
| Code: | | gentoo jsg # mkdir /var/log/portage |
Edited /etc/make.conf
| Code: | 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
| Code: | gentoo jsg # cfg-update --off
No (protected) directories found... |
Now what should I do?
Best regards
Jakob Simon-Gaarde |
|
| Back to top |
|
|
mirko_3
l33t
Joined: 02 Nov 2003
Posts: 605
Location: Birreria
|
| Posted: Sun Jun 12, 2005 11:53 am Post subject: |
|
|
| Code: |
mirko_3@mirko3 ~ $ cat /etc/make.conf|grep PORT_
PORT_LOGDIR=/var/log/portage
|
This, maybe?
_________________
Non fa male! Non fa male! |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sun Jun 12, 2005 8:18 pm Post subject: |
|
|
Yeah, it must have this line: | Code: | | PORT_LOGDIR=/var/log/portage |
| Code: | | 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...
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
|
Documentation, Tips & Tricks
