Dale wrote:
Gregory Woodbury wrote:
Has Alan ever posted his "jackhammer" script for some experts to look at?
I get by really well with a small script that reads the eix outputs, finds the "[U]"tagged packages, and then runs "emerge -u1" on that list.
Doing anything more than that will be a cause of pain and suffering.
If a package needs patches for something special, it is better to make a localrepository with modified ebuilds and distfiles, rather than try to force the gentoo repointo your own mess. I do this for a few tthings that Gentoo doesn't ship. Portageis actuallly quite flexible underneath, itt just takes a bit of learning.
He did a while back. Some very experienced Gentoo users here explained to him that his script was the problem. From memory which isn't all that good, it syncs the tree which is fine. After that, it gets bad. I think it did the updates and then repeated that several times within the script. That is done without him looking to see if anything needs to be changed, USE flags etc, or if something shouldn't be updated at all. I'm pretty sure that it then deletes all the logs of what was done, which means anything broken is broke and no record of what or even why.
Yes, some things can be done with a script. However, there needs to be a point in there where the user, the real brain of what is wanted, looks at the list of what will be updated. Only a human can look and see if there is USE flag changes or other issues that need a config file to be edited. Alan skips all that.
If you want, I can go dig it out and post it. I should have a copy of the script in my local email. I keep them for like 2 years or something then it deletes the old stuff. I'm not sure if you will laugh your head off or cry tho.
Dale
:-) :-)
What the heck. I went back and found it. It only took a few minutes. The rest of this message is the email where he has his script. I'll do my usual sign off at the bottom, rest is his post. For those who have already seen it, you might want to skip past the rest. No need torturing yourself again.
I use two scripts for all emerge use, the goal is to run one command and then walk away: Standard general update script: ####################### tortoise ~ # cat sysupdate #they must have moved or removed the logs, might have to track them down again... #rm /var/log/emerge* # cache /usr/portage echo "caching /usr/portage. This will take a long time." time ls -R /usr/portage > /dev/null emerge --sync layman --sync ALL emerge --update --verbose portage emerge --update --newuse --deep --with-bdeps=y system --keep-going emerge --update --newuse --deep --with-bdeps=y world --keep-going rm -f /var/cache/revdep-rebuild/*.rr revdep-rebuild emerge --skipfirst --resume emerge --skipfirst --resume etc-update eclean-dist ######################## The eclean line was added just a few days ago from this thread... This one is intended to be a nice gentle update script. It caches the portage tree, then syncs everything, then updates everything starting with critical system packages, then all world packages... Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too hard.... This next script is what I use when emerge starts giving me shit: ################## tortoise ~ # cat keepgoing emerge --update --newuse --deep --with-bdeps=y system emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --update --newuse --deep --with-bdeps=y world emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps rm /var/cache/revdep-rebuild/*.rr revdep-rebuild emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps emerge --skipfirst --resume --nodeps etc-update ################### It's basically the same as the working section of the above but instead of letting emerge do it's thing, it jackhammers that bitch as hard as possible to get as much updated as possible, but it requires emerge to do something and not error out for no good reason... I expect prune and depclean to be useless but I kinda need update to basically work every time. =\ Whatever fails on this script, I just live with until next week/month. ################### tortoise ~ # ./pretendupdate These are the packages that would be merged, in order: Calculating dependencies / !!! Problem resolving dependencies for sys-apps/util-linux from @system ... done! !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet requirements. - sys-apps/util-linux-2.27.1::gentoo USE="caps cramfs ncurses nls pam python readline suid udev unicode -build -fdformat -kill (-selinux) -slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 64 -x32" PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_4 -python3_3" The following REQUIRED_USE flag constraints are unsatisfied: python? ( exactly-one-of ( python_single_target_python2_7 python_single_target_python3_3 python_single_target_python3_4 ) ) The above constraints are a subset of the following complete expression: python? ( exactly-one-of ( python_single_target_python2_7 python_single_target_python3_3 python_single_target_python3_4 ) python_single_target_python2_7? ( python_targets_python2_7 ) python_single_target_python3_3? ( python_targets_python3_3 ) python_single_target_python3_4? ( python_targets_python3_4 ) ) (dependency required by "@system" [set]) (dependency required by "@world" [argument]) tortoise ~ # cat ./pretendupdate emerge --update --newuse --deep --with-bdeps=y world --verbose --pretend tortoise ~ # ########### Google is not being helpful with this... =(
Dale
:-) :-)