I tried to upgrade to 1.0 using the steps that were posted to the mailinglist and after relinking the make.profile and upgrading portage I get ACCESS DENIED mkdir: /usr/var/tmp/glibc-2.2.5 tar: glibc-2.2.5: Cannot mkdir: Permission denied /var is a symlink to /usr/var /tmp is symlinked to /var/tmp I see no problems with the directory-rights.
Geert: any ideas?
I found the problem with some help on the mailinglist: I had a symlink from /var to /usr/var and since I didn't change the TMP-Variables in make.conf it didn't work. I'm still not sure if this is the way it should work... At least I assumed that a symlink would be enough. And it worked fine until I started using Gentoo 1.0/Portage 1.8.18.
That probably means that sandbox (the component of portage that keeps packages from writing where they're not suppose to during compile time) was alerted and kept your package from writing to a non-std location. I would suggest that you write a bug report about this on bugs.gentoo.org Also, if you want it to work regardless, you can temporarily disable sandbox by adding FEATURES="" to your /etc/make.conf I say temporarily, because sandbox is normally a good thing, but as you can see, not all packages are sandbox clean yet. -Jared H. vo.chi.cong-linux@is.titech.ac.jp wrote: > Hi from Japan, > > When I tried to emerge latex2html, > after download the package and compiled it successful, > portage said: > > Note: trying to install LaTeX2HTML style files in TeX directory tree > (/usr/local/share/texmf/tex/latex/html) > ACCESS DENIED open_wr: /usr/local/share/texmf/tex/latex/html/floatflt.ins > Error (Copy): Copy "texinputs/floatflt.ins" to "/usr/local/share/texmf/tex/latex/html/floatflt.ins" failed: Permission denied > at config/install.pl line 397 > > Could you explain me what was "ACCESS DENIED" here in the error > message. I made sure that the folder is writable for root. > drwxr-xr-x 2 root root 4096 Apr 16 11:34 > /usr/local/share/texmf/tex/latex/html > > Thanks in advance. > > Cong
The /tmp symlink is the culprit. Portage 1.8.18 will get confused by this. It will not work with that version of Portage, nor will it get fixed. We strongly encourage you to upgrade your Portage version (by disabling the sandbox, if you require the symlinking to install properly). Portage will always verify against _actual_ directories that are written to, not the symlinks. This way, there is no way a package can write to /var by simply symlinking to it.