Am Mon, 29 Aug 2016 12:05:51 -0700 schrieb Daniel Frey <djqf...@gmail.com>:
> On 08/29/2016 11:11 AM, waltd...@waltdnes.org wrote: > > On Mon, Aug 29, 2016 at 06:29:50PM +0200, meino.cra...@gmx.de > > wrote > >> Hi, > >> > >> after updateing my system, beside others guvcview was updated: > >> > >> from qlop > >> Mon Aug 29 17:44:08 2016 >>> media-video/guvcview-2.0.4 > >> > >> After ldconfig as root and rehash (zsh) as user I got: > >> > [...] > >> guvcview: error while loading shared libraries: > >> libgviewv4l2core-1.0.so.1: cannot open shared object file: No such > >> file or directory [1] 23848 exit 127 guvcview > >> > >> > >> ...hmmmm. > >> > >> What did I wrong? > >> > >> Best regards, > >> mcc > > > > The first suggestion in a case like this is to run > > revdep-rebuild. As a matter of fact, it probably wouldn't hurt to > > run revdep-rebuild after every update. > > > > Yes, I do. Portage occasionally misses a rebuild. It's a lot better > now at catching them but it still misses them. I think this mainly happens for very old packages not built in a long time. The install database simply misses the relevant info. Rebuilding the package should catch up on this. I usually see this on old packages installed but not updated for a long time. "emerge @preserved-rebuild" usually doesn't see them, revdep-rebuild most of the time sees them but may miss packages which @preserved-rebuild sees (because revdep-rebuild does only detect missing binary deps but cannot identify orphaned libs which are still there but should be removed). And some simply need to rebuild once to migrate to new installation meta data. Packages caught in such a way are from then on usually seen by @preserved-rebuild. I'm using only "emerge @preserved-rebuild" in a long time now, without falling back to revdep-rebuild. The latter is quite obsolete to me. -- Regards, Kai Replies to list-only preferred.
