> On Feb 9, 2015, at 10:26 PM, Alexander Hansen <alexanderk.han...@gmail.com>
> wrote:
>
>>
>> On Feb 9, 2015, at 10:11 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>
>> On Tue, Feb 10, 2015 at 12:46 AM, Alexander Hansen
>> <alexanderk.han...@gmail.com> wrote:
>>>
>>> On Feb 9, 2015, at 8:52 PM, Jack Howarth <howarth.at.f...@gmail.com> 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
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
