app-portage/cfg-update - installation instructions

Message

xentric · Post by **xentric** » Sun Apr 20, 2008 9:40 pm

Ok thanks, added it to my TODO-list...

XenoTerraCide · Post by **XenoTerraCide** » Sun Jun 15, 2008 10:24 am

is cfg-update on a vcs anywhere?

xentric · Post by **xentric** » Fri Jul 11, 2008 7:27 pm

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

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 · Post by **SpineBuster** » Tue Nov 25, 2008 12:58 pm

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 · Post by **xentric** » Tue Nov 25, 2008 5:57 pm

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

TheHistorian · Post by **TheHistorian** » Fri Feb 13, 2009 10:40 pm

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

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 · Post by **rich0** » Sun Oct 02, 2011 10:54 am

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

ppurka · Post by **ppurka** » Sun Oct 02, 2011 11:25 am

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

ddriver · Post by **ddriver** » Sun Oct 02, 2011 11:30 am

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 · Post by **rich0** » Sun Oct 02, 2011 11:32 am

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 · Post by **ddriver** » Sun Oct 02, 2011 11:46 am

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:

Code: Select all

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

Code: Select all

  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 · Post by **ddriver** » Sun Oct 02, 2011 11:52 am

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 · Post by **rich0** » Sun Oct 02, 2011 11:53 am

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 · Post by **ppurka** » Sun Oct 02, 2011 1:42 pm

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 · Post by **ddriver** » Sun Oct 02, 2011 1:45 pm

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 · Post by **rich0** » Sun Oct 02, 2011 2:13 pm

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 · Post by **devsk** » Sun Oct 02, 2011 3:46 pm

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 · Post by **rich0** » Mon Oct 03, 2011 6:47 pm

I moved the update options earlier. You can download it at:

https://raw.github.com/rich0/cfg-update ... 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.

If feedback is generally positive I'll put that in the next release.

ppurka · Post by **ppurka** » Mon Oct 03, 2011 7:26 pm

rich0 wrote:I moved the update options earlier. You can download it at:

https://raw.github.com/rich0/cfg-update ... 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.

If feedback is generally positive I'll put that in the next release.

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 · Post by **rich0** » Mon Oct 03, 2011 7:29 pm

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 · Post by **rich0** » Mon Dec 05, 2011 7:37 pm

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 · Post by **xentric** » Thu Jan 19, 2012 8:55 pm

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

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 · Post by **devsk** » Thu Jan 21, 2016 9:30 pm

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 · Post by **rich0** » Sun Feb 28, 2016 10:47 am

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.

app-portage/cfg-update - installation instructions

new maintainer

Re: new maintainer

Update available for testing.

Re: Update available for testing.

stable versions coming soon...