*** Makefile.old        Tue Sep 11 04:38:03 2001    

  As I said, this patch is wrong for several reasons:       1) Does not take into account case when you install Mesa        then later remove it.  Right, Mesa should be a dependent on this port.  Which currently isn't but  should be regardless of the patch.     2) Removes files owned by the Mesa package if you install        blender after installing Mesa then remove it.  No, it just makes 2 sym_link_s that Mesa doesn't currently make, then deletes  them.     3) Replaces files installed by the Mesa package if you        install the blender package (as opposed to the port).  Why would a pkg install different files than a port? Could you expand on  that? I think im obviously overlooking something.   Port maintainer would be well advised not to integrate such a   broken patch.  If nothing else, however, the port maintainer  the broken patch makes the port unbroke 8)   might want to include a pkg-message file (or append one if it   exists) instructing the installing user to sym_link_   libGL[U,].so.14 to libGL[U,].so.1 or whatever it is X4   installed at that time.  If the user manually creates those sym_link_s, then uninstalls Mesa and/or  blender at a later time, niether will claim ownership of that file and will  leave the dead _link_ in the lib dir.  I _hate_ dirty /usr trees, thats how  things break 8)   This mess would be properly fixed if we had proper magic to   detect Mesa.  For example, Mesa should be split out into libglut   so there is no need for the Mesa package if X4 is installed.  As I mentioned earlier, im looking into Mesa right now to see what can be  done to fix this.  Really the only issues I see with the patch is that it  needs a PORTREVISION bump, a Mesa depend and the fact that Mesa is the port  that should be patched not the blender port.  I just submitted this patch  because it does temporarily fix things until you/I/maintainer/whoever can  come up with the proper solution.  

  Right, Mesa should be a dependent on this port.  Which currently isn't but   should be regardless of the patch.  Mesa dependent on blender?  I don't think so.   No, it just makes 2 sym_link_s that Mesa doesn't currently make, then deletes   them.  Hmm.  It is actually in graphics/Mesa3, but only included if  XFree86 is 3.x.  So your patch is still broken in this respect.  The Mesa port is broken too, but that's not addressed here.   Why would a pkg install different files than a port? Could you expand on   that? I think im obviously overlooking something.  Because the package is built in a clean environment.  If Mesa  installs a sym_link_ in that location and you build the port, your  command as in the port would fail because the sym_link_ already  exists.  And then your blender plist would be broken because it's  also claiming to own that sym_link_.   the broken patch makes the port unbroke 8)  No, it actually breaks it (more).  If something doesn't do the  right thing, it is by definition broken.   If the user manually creates those sym_link_s, then uninstalls Mesa and/or   blender at a later time, niether will claim ownership of that file and will   leave the dead _link_ in the lib dir.  I _hate_ dirty /usr trees, thats how   things break 8)  Dirty /usr trees don't really cause problems in this case, since  the sym_link_ wouldn't point to an actual file if the packages are  removed.   As I mentioned earlier, im looking into Mesa right now to see what can be   done to fix this.  Really the only issues I see with the patch is that it   needs a PORTREVISION bump, a Mesa depend and the fact that Mesa is the port   that should be patched not the blender port.  I just submitted this patch   because it does temporarily fix things until you/I/maintainer/whoever can   come up with the proper solution.  The port already depends on Mesa.  The patch is wrong.  It does  not really fix the problem.  By the way, I already had this long discussion with the author of  blender and the original blender port maintainer awhile back.  The short and long of it is that Mesa in ports needs to be fixed.  Please don't suggest to fix blender like this.  Someone else  already went down that road.  Regards,  

  Mesa dependent on blender?  I don't think so.  No, as i said Mesa should be a dependent, not be dependent, which it is, I  seemed to have overlooked pkg_info -r 8)   Hmm.  It is actually in graphics/Mesa3, but only included if   XFree86 is 3.x.  So your patch is still broken in this respect.   The Mesa port is broken too, but that's not addressed here.  Re-read the message you replied to.   Because the package is built in a clean environment.  If Mesa   installs a sym_link_ in that location and you build the port, your   command as in the port would fail because the sym_link_ already   exists.  And then your blender plist would be broken because it's   also claiming to own that sym_link_.    So packages that require X libs are built according to XFree86 3.x? Hrmm, I  see how that could get hairy.   No, it actually breaks it (more).  If something doesn't do the   right thing, it is by definition broken.  Breaks it less, now it actually runs. (given on a XFree86-4 box).  I agree  that its still broke, hence why I'm working on the Mesa3 changes.   Dirty /usr trees don't really cause problems in this case, since   the sym_link_ wouldn't point to an actual file if the packages are   removed.  Always better safe than sorry, scenario: some clown out there (there are  many) writes code w/ a configure _script_ to evaluate [ -e  /blah/blah/libGL.so.14 ] or [ -h /blah/blah/libGL.so.14 ] to check for Mesa3,  then someone ports it. kaboom.   As I mentioned earlier, im looking into Mesa right now to see what can be   done to fix this.  Really the only issues I see with the patch is that it   needs a PORTREVISION bump, a Mesa depend and the fact that Mesa is the   port that should be patched not the blender port.  I just submitted this   patch because it does temporarily fix things until   you/I/maintainer/whoever can come up with the proper solution.     The port already depends on Mesa.  The patch is wrong.  It does   not really fix the problem.  I had overlooked that depend and I am working on Mesa, see above,   By the way, I already had this long discussion with the author of   blender and the original blender port maintainer awhile back.   The short and long of it is that Mesa in ports needs to be fixed.  Then blender should be marked as a broke port until it isnt broke according  to your definition of broke.   Please don't suggest to fix blender like this.  Someone else   already went down that road.  I mearly offered it as a temporary fix.  I don't do things half assed.  Just  give me a little time to work on it and all will be well. 8)  

  So packages that require X libs are built according to XFree86 3.x? Hrmm, I   see how that could get hairy.  No, that's not what I said.  I said that what Mesa installs  depends on the XFree86 version it's built against.   No, it actually breaks it (more).  If something doesn't do the   right thing, it is by definition broken.     Breaks it less, now it actually runs. (given on a XFree86-4 box).  I agree   that its still broke, hence why I'm working on the Mesa3 changes.  If it breaks other ports in more than zero quite possible cases,  it is still broken from a packaging perspective.   Always better safe than sorry, scenario: some clown out there (there are   many) writes code w/ a configure _script_ to evaluate [ -e   /blah/blah/libGL.so.14 ] or [ -h /blah/blah/libGL.so.14 ] to check for Mesa3,   then someone ports it. kaboom.  I agree that it's better safe than sorry, but I still think your  patch is wrong for other reasons.     By the way, I already had this long discussion with the author of   blender and the original blender port maintainer awhile back.   The short and long of it is that Mesa in ports needs to be fixed.     Then blender should be marked as a broke port until it isnt broke according   to your definition of broke.  The port would not be broken by my definition if the maintainer  adds a pkg-message file to notify the user that due to brokenness  in the Mesa/XFree86 stuff, they will have to install the sym_link_  manually, if required.  This will make them aware of the issue  and to make sure they take care of it in the future should they  not require the sym_link_ any more.  It's not a perfect solution,  which is why...   I mearly offered it as a temporary fix.  I don't do things half assed.  Just   give me a little time to work on it and all will be well. 8)  ...you're working on that now.  8^)  

  ...you're working on that now.  8^)  feh, still, current-port < my-patch < mesa-fix