Been unable to emerge control-center because the old version of Xft.h (installed by xfree) was still on my machine, even though Xft is supposed to replace it with a newer version. The bug, IMHO, is this: # qpkg -f -v /usr/X11R6/include/X11/Xft/Xft.h x11-base/xfree-4.2.1-r2 # qpkg -f -v /usr/include/X11/Xft/Xft.h x11-libs/xft-2.0.1 Xft.h is the same file but installed in two "different" locations by the two packages, which prevented me from finding the problem for a week or so. I suppose I re-emerged xfree for some reason or other which overwrote the new Xft.h with the old one and the conflict was never noticed by emerge. Reproducible: Always Steps to Reproduce: 1.Note the version of Xft.h 2.Re-emerge xfree 3.Note the version of Xft.h Actual Results: Xft.h is now obsolete. Expected Results: I suppose emerge should force the re-installation of xft after re-emerging xfree? Or warn that a newer file is being replaced with an older one?
BTW I had another headerfile conflict on the same machine which may or may not be related. It is well-known (by everybody but me) that xfree may, under certain circustances, install its own (conflicting) version of zlib and its headers in the /usr/X11R6 tree. This prevented me from emerging some other package recently with a message that gzputs was undefined. I don't know why xfree decided to install its bogus zlib on this particular machine and not on my other two gentoo boxes, but it sure wasted a lot of my time. Any ideas why it occurs sometimes?
Your /usr/include/X11 should be a symlink .... -------------------------------- $ ls -ld /usr/include/X11 lrwxr-xr-x 1 root root 20 Mar 23 07:37 /usr/include/X11 -> ../X11R6/include/X11 -------------------------------- Fix this, remerge xft and then it should be fixed.
Yes, I did that before I filed the bug report. My problem with this fix is that I had to debug it before I could do it. I think the Xft package and the XFree package should both claim the header file in the same location so that the user is aware that the same file is installed by two different packages and they conflict. Is there some reason that this can't be the case? I don't claim any expertise in package management, but this seems an obvious fix.
Right. Foser, I thought xft installed to /usr/X11R6/include its headers ?
no it installs to /usr/include/X11 as said, which is ofcourse basicly the same. Only qpkg/portage doesn't notice that (that is the real problem here). I suppose i could look into installing it in the not symlinked path, but thats just hacking around the real problem. I guess there are more packs that install in symlinked dirs, which are all a possible cause of 'debugging problems' like this. I think setting prefix in the xft config to be /usr/X11R6 should be sufficient.
Dont think we should set the whole prefix, as moving the libs to /usr/X11R6/lib could have some issues .... what about just setting --include-dir ?
I have a fix locally which just changes the includes dir, will throw that in then. I noticed btw that all archs except x86 have 2.0.1-r1 as stable , shall i mark it stable x86 too ? I don't see this necessarily as a good thing btw, it is after all a release with a plain cvs patch.
This is fixed in -r2.
Heh, I commited new rev, and then posted prev when I noted a clash 8) CVS stuff is fixes if I remember corret.
