The chromium install process creates symbolic links to the nspr/nss libraries using relative paths. The problem is that these links will be invalid if there are any symbolic links relocating the installation directory to another path/file system. Reproducible: Always Steps to Reproduce: 1. Install chromium-bin 2. Attempt to start chromium-bin Actual Results: Initial startup fails due to failure to find the nspr/nss libraries. Expected Results: Chromium install should not link to libraries that do not exist. Minimally it should check to see if the relative paths exist and if not link to the default (standard) paths where the nspr/nss libraries are supposed to be. I can correct this by running a shell script following an install to fix the links but I shouldn't have to do this. The Gentoo install process should make sure that required links exist or inform the user of the problem. (Informing is better than failing since at least the install finishes and can be corrected. Failure due to missing libraries on the other hand would presumably leave the update uninstalled and require the user to go track it down in the portage directories). It should be noted that current chromium-bin releases seem to have a severe problem leaving around <defunct> children which eventually makes chrome and/or the gnome session unusable due to hitting the number of processes ulimit. This is filed with the chrome developers (Issue #23778). It would be nice for chromium-bin to list the build date for Gentoo versions. I've got no way to relate the Gentoo versioning (4.0.251.0 (32167)) with the Chrome continuous builds @ google (which only seem to be listed by build date). So I have no way of knowing how far behind the curve I am without downloading, installing and attempting to run the LATEST version from Google to attempt to compare the version information. If I'm downloading the latest Google version that makes the Gentoo release of binaries rather pointless. On the other hand a Gentoo release of the source would be rather useful even though the build time is probably somewhere between firefox and openoffice (e.g. hours).
Sorry but I don't understand the problem with nss/nspr symbolic links: you do not have them on your system at /usr/lib(64)/nss and /usr/lib(64)/nspr? (which are the default standard paths for them). As nss and nspr are in RDEPEND, these libraries missing on your system indicate a bigger problem I've not seen defunct processes since some time, but I'll make a version bump when this bug gets fixed upstream For versioning, the Gentoo version is exactly the same as upstream version, check the "about chromium" box or googlechromereleases.blogspot.com for example. The tarballs are downloaded from http://build.chromium.org/buildbot/snapshots where the sorting is done by SVN version, not date? (you may find the date of a specific SVN version by looking it up at src.chromium.org/viewvc/ though). Oh, and chromium from source is available in Gentoo too ;) This is www-client/chromium
The symbolic link problem is that on my system /opt is a symbolic link to /var/opt so the install directory is really /var/opt/chromium.org rather than /opt/chromium.org. The links from the lib directory to the nspr/nss libraries are "relative", i.e. ../../../usr/lib/... (or something like that) which will not work because my directory tree is one level deeper than systems where /opt is an actual directory rather than a symbolic link. Its easily fixed by removing the relative symbolic links and recreating them as full path links to /usr/lib/... To avoid having to do this I'm simply requesting that the install process check to make sure the links actually work before creating them (and either adjust for the real installation path differences or use absolute links). [I don't see why one is using relative links in the first place as it requires going through more directories to get to them -- which even though they are likely cached probably requires additional CPU overhead in the kernel.]
Ah yes I see the problem now! The relative paths for nss/nspr symlinks were to workaround a QA warning (absolute symlink in a library directory warning), I'll see what I can do (updating the QA check to make it optional for such binary packages, or linker scripts instead of symlinks to make it happy)
OK, the QA warning was triggered because I called the destination directory lib/, I've renamed it and now symlinks are absolute (4.0.251.0 and 9999 ebuilds) without triggering the QA warning Thanks for the report!
