Josh Sled wrote: > "John P. Burkett" <burk...@uri.edu> writes: >> My weekly routine has been to do >> eix-sync >> emerge -D -uav system >> emerge -D -uav world >> When the responses have suggested doing "revdep rebuild", I've done so. >> >From now on I'll try to follow your good example of upgrading twice a >> week. Whether I should add "emerge --depclean" to my upgrade routine is >> not so clear to me. Perhaps it should only be used by people who know >> more than I do. > > I'd suggest always doing a revdep-rebuild. It doesn't take *too* long, > and will pick up things that maintainers might miss (or expect you to > pick up doing a revdep-rebuild). > > While on the topic, I'd suggest adding '-N' (--newuse) to your emerge to > pick up any USE flag changes that happened to creep in. > > As well, `eclean-dist -d -f` to clean up obsolete > /usr/portage/distfiles/ entries. I follow this by `emerge --depclean > -pv` for review and manual action of packages I know or can verify are > unused; big system-level things like gcc or glibc often get a pass, > though. :) > > As well, `glsa-check --list` for review, followed by something like: > > glsa-check --inject $( glsa-check --nocolor --list new \ > | grep '\[U\]' \ > | awk '{ print $1 }' ) > > ...to inject GLSA entries that your system is unaffected by, and > generally maintain the GLSA list. > > As well, depending on which ELOG system you're using, you might want to > use `eread` to review and clear out the entries from newly-installed > packages, though it sounds like you're already doing so. I generally > use the mail ELOG system, and now have 280+ saved logs to step through > and clear one. at. a. time. :/ > Thank you, Josh. I'll try your suggestions this weekend.
My first priority now is to respond to the error message mentioned in my 9:11 a.m. note: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory. Trying to see what related files are on my computer, I did "locate libgfortran.so" and got the following response: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/32/libgfortran.so /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/32/libgfortran.so.3.0.0 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/32/libgfortran.so.3 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libgfortran.so /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libgfortran.so.3.0.0 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libgfortran.so.3 To start R, octave, and other applications that look for libgfortran.so.1, I presumably need to either reinstall libgfortran.so.1 or rebuild the applications so they look for libgfortran.so.3. It's not obvious to me which approach is better or how to implement either. I'd be very grateful for suggestions. Best regards, John -- John P. Burkett Department of Economics University of Rhode Island Kingston, RI 02881-0808 USA phone (401) 874-9195