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 <howarth.at.f...@gmail.com>
> 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 <alexanderk.han...@gmail.com>
> 
> 
> 
> On Wed, Nov 2, 2016 at 7:48 PM, Alexander Hansen <alexanderk.han...@gmail.com 
> <mailto:alexanderk.han...@gmail.com>> 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
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to