Hi, Please find attached, the cfg-update-1.2.ebuild I suggest apps-portage/cfg-update This ebuild has only been tested on x86 cfg-update is an easy GUI & CLI alternative for etc-update and allows users to update their configuration files safely. Overwriting of the current configuration file with the ._cfg0000_ file is only allowed when the current file has not been modified after it was installed by portage. Backups are automatically made before each update and they can be restored easily. Stephan
Created attachment 20259 [details] cfg-update-1.2 (New package) I suggest app-portage/cfg-update !
Created attachment 20929 [details] cfg-update-1.3 (New package) The initially submitted 1.2 version is made obsolete by this new 1.3 version! I hope this ebuild can be added soon as: app-portage/cfg-update Thanks, Stephan
Created attachment 21852 [details] cfg-update-1.4 (New package) Version 1.2 and 1.3 have not yet been included in the main Portage Tree. Therefore I suggest to include the latest version which is now 1.4. I hope it will be included as: app-portage/cfg-update Message to maintainer: Can you give me an estimate how long it will take to test and include my package into the Portage tree? Or how many packages/bugs are waiting to be handled before my package? I'm not impatient, just curious about the workload for maintainers like yourself...
I suggest we put this into Gentoolkit, as we release the 0.2 series in January. I certainly don't want more dangling ebuilds in app-portage than necessary, and this script will naturally need to go through some more real-world testing before unleashing it on the general populace. I'll see if I can't look into it after xmas. Give me a few weeks. Sorry about the delay. We are working as fast as we can while also trying to have a social life and shopping xmas presents.
I don't read perl so I'll leave it to Karl or Aron ;)
Created attachment 23672 [details] cfg-update-1.5 (New package) I have fixed a bug in cfg-update. Updates in /etc/init.d need to be executable, so the script now checks if the original config file (or init script in this case) was executable and sets the updated config file accordingly. The script now uses strict, so some variables are not global anymore that shouldn't have been global in the first place. Further optimizing will happen in future updates... As far as I can see, the README file of gentoolkit now states that only python and bash scripts are accepted. This probably means that my perl script won't be in gentoolkit. So again I suggest either a stand-alone package like "app-portage/cfg-update" but if you guys don't have enough time to manage a new package, please try to make a deal with another category maintainer, maybe "app-admin/cfg-update" would be a good idea... A lot of users ask me when the cfg-update ebuild will be available through the main portage tree. They have been waiting on it for a while now and they have to keep checking the page on the forums to see if there are any updates or bugfixes. I understand your position, you've got a lot of work to do, but I really want to find a quick solution for this. Can you pass my package to a maintainer who has more time and will put my ebuild it in the portage tree?
Created attachment 25361 [details] cfg-update-1.6 (New package) This update fixes problems with backups in /etc/init.d being run on startup. See changelog, or http://forums.gentoo.org/viewtopic.php?p=853568#853568 for more information.
Created attachment 26417 [details] cfg-update-1.6 (New package) Location of the tarball changed and the ebuild does not automatically convert the old backups to the new format anymore. This changed because new and future installs should not have to spend time looking for files that have been converted already or are non existent.
Any progress in accepting cfg-update as a package yet?
Karl?
I just want to add some info about the script! Today (9th June 2004) cfg-update v1.6 has been downloaded for installation exactly 350 times. Last minor issue (not even a bug) was reported in February and all major flaws have been corrected every single time. No unresolved bugs. I conclude that the real-world testing phase has been a success. As for package complexity, the ebuild doesn't even have to compile stuff. It only installs 2 perlscripts, some documentation and it creates an alias so it can keep it's checksum-index in sync with portage... Really simple stuff that just works! And the most important thing is that the users who use it haven't messed up their config files anymore while still seeing others report their troubles with etc-update almost daily. I wrote this script especially to stop the large amount of problems with the handy etc-update tool. But it looks like you guys rather worry about having too many packages in app-portage than about the users who screw up their systems with etc-update. This simple package can benefit a lot of new (and experienced) users so please accept it. I owe it to all the people already using it to get the package in the portage tree. They've been waiting since Nov 2003 !!! Karl?
Created attachment 35968 [details] cfg-update-1.6 (New package) Textutils now included in coreutils package, changed the ebuild dependency.
Created attachment 36602 [details] cfg-update-1.6 (New package) Changed einfo text in pkg_prerm()
Why is this taking so long? Monsieur Kalleberg, your last comment was over a year ago. I have been using this on 4 machines and cringe everytime I setup another machine and see that it is STILL not in portage. Why do really unstable things make it into portage and this which is very stable and safe can't ? If you personally don't want this to go in could you explain why and re-assign it to someone more open minded. I can't think of any logical or good reason not to have this added to portage. You are discouraging people from making gentoo better. I would see it as a great tragedy if other people like Monsieur Boven were disuaded from making contributions because of your handling of this situation. Merry Christmas to you and perhaps consider adding this to portage as a small present to the gentoo community when you come around to reading it ? Cheers, (a rather dissatisfied) TightCode
Please take a look at this package. It is infinitely easier to do the diffs on config files in a GUI environment. I had been using this script for 6 months before my rebuild and never had a problem with it. Please get this in portage. Sincerely, Karl
Created attachment 49390 [details] cfg-update-1.7 (New package) Added USE-flags to the ebuild. If "kde" or "qt" flags are found, xxdiff will be installed. If the "gnome" flag is found, meld will be installed. This should make it easier for people with gnome-only, kde-only or no-X systems... The script now also works better with other diff/merge tools. As long as you can save the merged result over the current config file OR as current_config_file.merge you are OK. And after waiting more than a year, it would be nice if someone actually got this into the portage tree !!!
Created attachment 49541 [details] cfg-update-1.7 (New package) 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" or copy the latest v1.7 ebuild. Otherwise you can encounter an error when updating your system: <example error> root@gentoo / $ 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. </example error> Just change line 18 from: gnome? ( >=dev-util-meld-0.9 )" to: gnome? ( >=dev-util/meld-0.9 )"
Created attachment 49884 [details] cfg-update-1.7 (New package) Fixed a small bug in the ebuild (thanks to tightcode) When upgrading the events are in this sequence: 1. Version 1.7 is installed - pkg_postinst() turns the alias ON 2. Version 1.6 is uninstalled - pkg_prerm() turns the alias OFF So the user ends up with the alias OFF and the checksums are not being updated anylonger... Fixed: alias will not be turned OFF in pkg_prerm, an einfo now tells the user to disable it manually if they remove cfg-update from their system.
Poke... Simply to voice my support that this utility should definately be in portage, I have been using it since it's infancy and hav _never_ had a problem with it and find it a crucial addition to portage for easing the managability of system updates.
There's a bug when using cfg-update from within a Screen session, it does not make use of xxdiff. Kinda annoying, but the work around (for now) is to exit Screen. So you know.
Bel Z
Bel Zébute: Are you able to manually start an X application (ie:xxdiff) from your Screen sessoin to start with? Because, if you can't, cfg-update won't be able to either.
where is the vote botton?!?!? I want this tool in the portage tree... :(
Once again, yet another satisfied user who would very much like to see this hit portage. I understand that this bug reporting system is not meant to be used as a forum for this, but in this case this is a VERY useful tool which has proven itself over time and I honestly cannot see a single reason why it should not be available via portage. Just another faithful gentoo user (although slightly peeved over this man's struggle) Matt
What is required to get this in portage? Granted I don't know everything - and I shall be the first one to admit it - but it seems to me based on what little information I have that not having the tools people want in the distribution is hurting it far more then internal politics or people being butt-hurt about there own work being depreciated ever could. This needs to be in portage ASAP.
Hi, right now I see some problems with cfg-update. Firstly, if I run cfg-update -u (or rather, sudo cfg-update -u) as I believe I'm supposed to, I'm greeted with this: Use of uninitialized value in substitution (s///) at /usr/bin/cfg-update line 242. Use of uninitialized value in pattern match (m//) at /usr/bin/cfg-update line 243. xxdiff not found... It doesn't look like it's reading CONFIG_PROTECT properly, and it tries to use xxdiff (unless I specify --cli) even though I installed it with USE="-kde -qt". Also, it doesn't parse make.conf properly; it simply greps for ^PORT_LOGDIR= instead of calling portage, or sourcing make.conf and echoing it. And env | grep '^TERM='? :) The ebuild could use a little bit of cleaning up too, but there's not as much there that's actually a problem. If you could handle this, make it a bit more suitable to work by default on different systems, I don't see any other reasons against adding it right now.
Great pice of software!!! should enter in the portage tree.
Created attachment 57330 [details] cfg-update-1.7.1 (New package) After fixing the bugs and problems, pointed out by Harald, and backporting new stuff from the development version 1.8.0 into 1.7.1, I can finally say that version 1.7.1 is ready to be added to the portage tree... * It now has better support for different tools. * If the tool is missing, it tries to use other tools before dying gracefully. * It determines if a GUI is available by looking at the DISPLAY variable. * It doesn't show warnings about empty variables anymore. * The ebuild has been cleaned out and the USE-flags have been improved for better dependency control. * I have not changed the way it determines the protected directories, but I have fixed the unnecessary warnings caused by an empty CONFIG_PROTECT variable. I have tested the ebuild and the script extensively and it's safe to say that it is ready to be released :) I have some questions regarding migration into the tree though... What happends to users who have installed cfg-update in the portage overlay dir? Most users will have followed my installation directions and have probably saved the ebuild in /usr/local/portage/app-portage/cfg-update/ If cfg-update-1.7.1 is added to the tree, will they experience problems if they don't unmerge the previous version of cfg-update, which is an overlay package? Or do they only experience problems if the category differs from the category used for the overlay package?
I'll try to take a look at this later today. And don't worry, it won't cause problems for users who have it installed via an overlay already. Those users will simply continue to use the ebuild in their overlay, until a higher version than in their overlay is in the portage tree. If the category would be different (it won't be), it might indeed cause problems, but it would still be nothing that an unmerge of the old ebuild followed by an emerge of the new wouldn't fix.
Sorry, can't add it now, since it doesn't work properly anymore now that CONFIG_PROTECT is set in the profiles instead of /etc/make.globals. It doesn't find any dirs to protect (other than whatever may be in the environment). You may want to consider just asking portage for the vars instead of handling it yourself. (Also, I noticed it automatically copied files to /root. Please don't do that, even if you only do it when they don't yet exist.)
Ok, I can fix the CONFIG_PROTECT issue so it get's the dirs from emerge info, but that would make it very slow as this will introduce a 30 second delay... Etc-update takes the protected dirs from ${CONFIG_PROTECT}. My fear was that some systems do not properly set up the environment, so ${CONFIG_PROTECT} is missing the dirs specified in /etc/make.globals. That's the reason why I let cfg-update take the dirs from that file too. I just saw that etc-update does take ${CONFIG_PROTECT_MASK} into account, but I figured that only portage itself needs to exclude those dirs from the protected dir list because it needs to know what files it can or cannot overwrite. Etc-update and cfg-update only use the CONFIG_PROTECT values to speed up the search for ._cfg files, so they don't have to search all the dirs on the system... so ignoring the dirs in CONFIG_PROTECT_MASK will only make the searches slightly slower, that's all. I will think about a new way to get all CONFIG_PROTECT values we need, until then I will implement your suggestion where portage tells us what dirs are protected. Maybe I can just keep copying the method used by etc-update as that tool will probably be fixed very soon to be able to work with the new profile structure too... I now realise that writing those files to /root isn't even necessary anymore because x11-misc/sux fixes all permission related problems that users experienced when using su to run cfg-update. I will still copy the files to /usr/lib/cfg-update/ as example files, but the script won't put them in /root anymore...
By the way, I noticed that after updating portage (if I remember correctly) I was instructed to link /etc/make.profile to /usr/portage/profiles/default-linux/x86/2005.0 I have looked at the other profiles, most have a make.defaults file specifying CONFIG_PROTECT, but the default profile that portage recommends in the einfo/ewarn text doesn't contain this make.defaults file so the new portage still takes the CONFIG_PROTECT values from /etc/make.globals too?
Created attachment 57517 [details] cfg-update-1.7.1 (New package) I have fixed the CONFIG_PROTECT issue, it now get's the correct dirs from portageq. The ebuild has been changed so it doesn't run the --check option, which places 3 files in /root. I have renamed this function to --fix and the user can run it manually after reading in the manpage what it fixes and how it fixes that... Because this fix isn't run during installation anymore, it required me to build a new "alias-check" into the script. This checks if the emerge alias is set and advices the user to read the manpage and use the --fix option to enable proper operation. But at least the user now has a choice if he wants to copy the 3 files to root, which is the correct way of dealing with this! I have updated the tarball and I really hope I have resolved all issues now... If not, I'll just continue to fix them one by one :)
Okay, there are still some things I'd like you to change, but nothing that'll likely actually cause problems right now, so I'll just let you know about those later as a request for a newer version. I cleaned up the ebuild, and it's in portage now. In the future, please don't update the package without updating the version number, by the way; I had trouble figuring out why I didn't see the changes :)
