You are not logged in.

#1 2012-11-25 20:04:03

jrapdx
Member
Registered: 2012-11-24
Posts: 10

Problems re-emerging fox and freeglut after mesa-9.0.1 upgrade

Trying to keep Funtoo up to date, after routine upgrade to mesa-9.0.1, emerge reported freeglut and fox were still using the old mesa libs.  Normally, re-emerging the packages easily re-compiles/links programs to use the new libs.

To my surprise, during emerge freeglut and fox both halted with similar errors re: not finding "GLU.h" headers, which both packages required.  This was strange since previous upgrades had not been troublesome at all.

Checking it out, sure enough /usr/include did *not* contain a GLU.h file anywhere, though mesa does install libGLU.so.x files in /usr/lib64.  Looking at the ebuilds, freeglut, but not fox, lists a dependency on "virtual/glu", which was already installed on this system.

Since there was no indication that anything else was out-of-date, it was very puzzling.  After a while I wondered if "virtual/glu" was somehow involved, and just for kicks re-emerged it.

Sure enough, up popped "media-libs/glu", despite the presence of mesa being installed.  I decided to proceed, and as could be anticipated, there was a conflict with libGLU* files (from mesa) already present.  Emerge installed them anyway, with the usual "file conflict" warnings displayed.

I figured only the headers from media-libs/glu were really necessary, and that the alternate libGLU* installed (by glu) would probably be incompatible with the mesa package.  So I re-emerged mesa (which did not disturb GLU.h headers in /usr/include/GL), after which emerge of fox and freeglut went smoothly.

Awkwardly, mesa does not install GLU.h headers.  This causes problems when other packages insist on having these headers.  It's hardly ideal to have to install media-libs/glu just to get the GLU.h headers, and afterwards making sure to overwrite the libGLU files by installing mesa. 

This is compounded by virtual/glu seeming to be a requirement for fox, but not listed as a dependency.  Furthermore, as it stands, virtual/glu was not scheduled for update when it appeared to be necessary.

Seems to me, at present the sequence would have to be to update virtual/glu, install mesa libGLU.* over those of media-libs/glu, then re-emerge fox and freeglut.  Shouldn't we regard this as an ugly hack at best?

A much better solution would be to install the GLU.h, etc., headers along with mesa, since they are required by a number of GL-dependent packages.  Given that media-libs/mesa installs libGLU.* files, it's odd that the headers are not also provided.

JRA

Offline

#2 2012-11-25 22:40:33

rakiner
New member
Registered: 2012-06-22
Posts: 7

Re: Problems re-emerging fox and freeglut after mesa-9.0.1 upgrade

This was done intentionally as GLU was removed from the mesa git: http://forums.gentoo.org/viewtopic-t-93 … art-0.html

You should have installed media-libs/glu automatically when updating: emerge -uaND @world... Did you not use the deep flag perhaps?

Offline

#3 2012-11-29 09:31:58

jrapdx
Member
Registered: 2012-11-24
Posts: 10

Re: Problems re-emerging fox and freeglut after mesa-9.0.1 upgrade

rakiner wrote:

This was donintentionally as GLU was removed from the mesa git: http://forums.gentoo.org/viewtopic-t-93 … art-0.html

You should have installed media-libs/glu automatically when updating: emerge -uaND @world... Did you not use the deep flag perhaps?

Yes you are right--glu not installed automatically, hence with a bit of effort I finally installed as noted.

And right again.  I did not use the -D flag.  In the past I found -D added to the emerge invocation resulted in a lot of gnarly incompatabilites , blocked packages and other kinds of torment.  So I started using just -ua which went a lot smoother, well, most of the time.  The problem I reported didn't happen very often.  But I imagine the effects of not using -D could be cumulative and it caught up with me, at least this time.  On the whole though, at least up to now, my approach seemed least of the evils.  But I don't know, maybe things have improved, and I'll have to try modifying my ways.

Frankly, the number of "gotchas" appears to have increased over time among the Portage tools.  Maybe it's just gotten more complex and hard to "get it right', but from the user's point of view, it gets increasingly frustrating.

It would help tremendously to improve and clarify documentation, simplify the often opaque and uninformative error messages (e.g., "blocked packages") and give more explicit guidance to solution of problems when they arise.  The  man pages aren't much help resolving the confusion.  What's needed is simple, step-by-step instructions on resolving the impasse.  And  please, minimize the opaque and dire warnings that I'm sure are tremendously off-putting to even moderately-experienced users.

Yes, even us old-hands could benefit not only from simpler and less obscure instructions, better diagnostics when it doesn't go right, and above all a more robust and less error-prone package system.

Last edited by jrapdx (2012-11-29 09:38:36)

Offline

Board footer

Powered by FluxBB