Fwd: Apparently libXt isn't actually a leaf on the X11 library tree after all

Since I don’t plan to do all of this myself (or possibly at all), and because I am completely fed up with people sending me direct emails about packages that I don’t own, forwarding on.

> Begin forwarded message:
> 
> From: Jack Howarth <[email protected]>
> Subject: Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all
> Date: November 2, 2016 at 18:43:47 PDT
> To: Alexander Hansen <[email protected]>
> 
> 
> 
> On Wed, Nov 2, 2016 at 7:48 PM, Alexander Hansen <[email protected] <mailto:[email protected]>> wrote:
> We had thought that libXt wasn’t actually linked in the X11 tree, but this appears not to be so.
> 
> It’s linked by:
> /opt/X11/lib/libXaw6.6.dylib
> /opt/X11/lib/libXaw7.7.dylib:
> /opt/X11/lib/libXaw8.8.dylib:
> /opt/X11/lib/libXaw3d.8.dylib:
> (these may not matter since we’ve got libxaw3dxft2)
> /opt/X11/lib/libxkbui.1.dylib
> /opt/X11/lib/libXmu.6.dylib
> 
> The last one appears to be what is causing runtime failures with xemacs, since xemacs links to /opt/X11/lib/libXmu.6.dylib and to /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from libxt-shlibs.
> 
> Unfortunately, the whole rationale for having our own libxt (not so much for libxt-flat) was to try to provide a consistent libXt so that people wouldn’t have things break when updating from Xquartz 2.7.8 to later versions where libXt has been mucked with.
> 
> Here are some options:
> 
> 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
> 2)  Ditch libxt, and force people to install Xquartz-2.7.11.  Right now we’d have to use the “system-pkgconfig-xorg-server” virtual package to do this.  In principle we could adjust system-xfree86* to get the aggregate Xquartz release version instead of the “2:7.2” that we’ve been using for ages, but I don’t know if that gets stored anywhere but the package receipt, and that’s somewhat fragile to rely on.
> 
> 
> For the near term, option 2 certainly sounds like the best approach. We will have to build our way of  the current mess to eliminate linkages on libxt-shlibs as those may have other subtle destabilizations that we haven't noticed yet. Also libxt puts the onus on the package maintainers to avoid non-deterministic builds.
> 
> As for libxt-flat, it should be replaced with a buried copy like what I originally proposed. The universe of software that uses motif is small and isn't going to get any larger so it is very manageable to deal with. Sadly all of the packages which were updated in the last week will have to be redone.
>  
> We’d want to adjust the fink-package-precedence script appropriately for whichever option we pick.
> 
> #2 seems like the least work in the short term, but I know that some folks in the community don’t like it when we force dependencies on particular versions of non-Fink tools (e.g. the Xcode CL tools).
> #1 would rely on some kind soul being willing/able to maintain a Fink Xquartz, and we’d have to modify our existing X11-using packages to use only a Fink Xquartz.
> 
> Though I’m leaning towards the following options:
> 
> 3)  Stop bothering with X11 packages
> 4)  Give the hell up
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
Fink-devel mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel