Re: fink 0.38.4

> On Feb 9, 2015, at 10:26 PM, Alexander Hansen <[email protected]> wrote:
> 
>> 
>> On Feb 9, 2015, at 10:11 PM, Jack Howarth <[email protected]> wrote:
>> 
>> On Tue, Feb 10, 2015 at 12:46 AM, Alexander Hansen
>> <[email protected]> wrote:
>>> 
>>> On Feb 9, 2015, at 8:52 PM, Jack Howarth <[email protected]> wrote:
>>> 
>>> Alexander,
>>>      So we are taking the position that users shouldn't be expected to
>>> reinstall Xquartz after OS X reinstalls?
>>>              Jack
>>> 
>>>> 
>>> 
>>> Do they need to?  If only the convenience symlink is missing, then that’s
>>> idiotic.
>> 
>> Alexander,
>>         We should at least be consistent. If we aren't going to
>> provide maintainers with an expectation that /usr/X11 and/or /usr/X11R
>> will always exist, how can be rationally allow packages to pass...
>> 
>> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>> 
>> on ConfigureParams which then effectively lies to configure about
>> those locations? Also, how can the nonexistence of /usr/X11 and/or
>> /usr/X11R not break the many package whose builds currently set
>> -I/usr/X11/include or -I/usr/X11R6/include on CPPFLAGS, CFLAGS and/or
>> CXXFLAGS as well as -L/usr/X11/lib or -L/usr/X11R6/lib on LDFLAGS.
>> Never mind those instances in the cmake builds where CMAKE flags are
>> passing those paths for the X11 headers and libs.
>>               Jack
>> 
> 
> 
> Those should be updated.  The existence of the symlinks historically was enforced half-assedly in fink, where some virtual packages looked for items only in /usr/X11R6, and some allowed /usr/X11.  
> 
> The only legitimate reason to have /usr/X11R6 in the mix was so that packages could maintain compatibility with 10.4 so that maintainers didn’t have to bother to diff between .infos in different trees.   That hasn’t been supported for a long time now, and I didn’t think that going back into the X11 configuration of the past was a good idea for the future.  /usr/X11 is still necessary for 10.7 compatibility, of course, so we can’t really get rid of that until we ditch 10.7 finally.
> 
> I’d argue that we maybe could get some use out of either an enhancement to one of our build helper packages (like fink-buildenv-modules) or a new package.   We could have that set some environment variables like X11_INCLUDES, X11_LIBS based on the real supported X11 tree of the OS version in question, and other packages could use those.
> 
> Also, I’d argue that packages which link to X11 should have been revision-separated between 10.7 and 10.8, because in the former case they link X11 libraries with install_names containing /usr/X11 and in the latter those contain /opt/X11, because that’s a supported upgrade path, and without the symlinks the potential for runtime breakage exists.
> 
> On the other hand, going between 10.9 and 10.10 losing the symlinks produces no runtime breakage, because the library install_names all contain /opt/X11.  
> 

After further reflection on this, I’m moving toward the idea of enforcing the presence of /usr/X11->/opt/X11 on 10.8 and later, at least until we discontinue 10.7 and 10.8, in view of the potential runtime breakage issue above as well as the widespread need to reference /usr/X11.  Explicit use of /usr/X11R6, on the other hand, should probably trigger a validator warning.

However, be advised that there is NOT going to be a notice to users that they’re missing the symlink.  VirtPackage.pm isn’t supposed to echo anything under the conditions which fink invokes it.  So we’d go to go back from messages about not being able to find some file or directory provided by Xquartz to “no such package: x11-dev”.

The fundamental issue here is:
1)  We’re using x11* for the dependencies for historical reasons.
2)  x11* are Provides of system-xfree86*, and so they don’t directly utilize the faux CompileScript struct which provides users with a little feedback about what they need to do.
3)  system-xfree86* are set up to be _nonexistent_ when their requirements aren’t met, rather than _existent but not installed_, and this short-circuits the faux CompileScript.  

I’ve generally been a proponent of having items that can _potentially_ be installed on a platform at least show up under “fink install", because of the better user feedback, so addressing item 3) should help.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
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