Re: FreeBSD GNUstep ports proposal

[Matt Rice]

On Wed, Apr 15, 2015 at 4:52 PM, Lars Sonchocky-Helldorf
<lars.sonchocky-helldorf@hamburg.de> wrote:
>
> Am 15.04.2015 um 17:24 schrieb Matt Rice:
>
>> On Wed, Apr 15, 2015 at 7:48 AM, Matt Rice <ratmice@gmail.com> wrote:
>>> On Wed, Apr 15, 2015 at 12:53 AM, David Chisnall <theraven@sucs.org> wrote:
>>>> On 14 Apr 2015, at 21:13, Lars Sonchocky-Helldorf 
>>>> <lars.sonchocky-helldorf@hamburg.de> wrote:
>>>>>
>>>>> I never thought about it this way. This would be my first practical use 
>>>>> of Openstep search domains. Are there any pitfalls or things to consider 
>>>>> when using those or is the whole thing straight forward, e.g. anything 
>>>>> inside ~/Library/ automatically takes precedence over anything inside 
>>>>> /Library/ which precedes /Network/Library/ which precedes 
>>>>> /System/Library/, right? What about having different versions in 
>>>>> different search domains? Will those interfere? Sorry for those probably 
>>>>> stupid questions, I just never before came across to actually use that 
>>>>> stuff before.
>>>>
>>>> Versions in Local will take precedence over versions in System, but that’s 
>>>> not a problem if you have a different SONAME.  If you make sure that the 
>>>> GNUstep libraries that you’ve built have a newer .so version then things 
>>>> linked against the old version will find the version in System, things 
>>>> that you compile yourself will use the newer version.  And each framework 
>>>> will find its own copy of the resources.
>>>>
>>>> I’ve tried to make sure that all of the GNUstep packages in FreeBSD 
>>>> install in the System domain - let me know if I missed any...
>>>
>>> To me installing multiple versions of the same libraries in different
>>> domains seems like a disaster waiting to happen, where things like
>>> base's SSL bundle in System could potentially be loaded into a program
>>> linked to the base in Local, and causing the program loading the
>>> bundle to load multiple versions of base.
>>
>> FWIW it strikes me that this isn't necessarily the case for the SSL
>> bundle since it installs into a place where gnustep-base should only
>> be able to find it, and that place is versioned to the base version it
>> is built for,
>>
>> but it seems like something when installing various versions of things
>> in different domains, and the GNUstep domain system is generally not
>> intended to be used this way.  Unlike the unix /usr/, /usr/local/
>> heirarchy where a program installed into /usr/local generally looks
>> for its things in some subdirectory of /usr/local/, a gnustep thing
>> installed into any system/local/whatever domain may look for things in
>> any system/local/whatever domain.
>>
>> further the bundles are looked up by name, and it's the loading
>> programs responsibility to remove duplicate entries, and they may not
>> necessarily remove duplicates in the correct order, I've certainly
>> seen programs which list multiple versions of the same bundle name in
>> a preferences list before.
>>
>> Thins like gui's TextConverters bundles could be a problem such as this...
>
> I am understanding the issue right, that for every 
> framework/library/bundle/resource used the domains are traversed each time?

Yeah, see NSSearchPathForDirectoriesInDomains... except for resource,
the Resources/ subdirectory of a framwork/bundle/library is generally
private to it's parent

http://www.gnustep.org/resources/documentation/Developer/Base/Reference/Functions.html#function$NSSearchPathForDirectoriesInDomains

it's set up like this so that if the system or network administrator
installs an application/library/framework in their repsective
System/Network domain,
a user can install a bundle which the system/network
application/library/framework loads in their User domain (to which
they have permission to write to)

> In other words, if framework A exists in System and in Local and a framework 
> B uses framework A and exists only in System it takes the one from Local and 
> not the one from System (which was probably intended to be used) or are the 
> mechanics of loading frameworks/libraries/bundles/resources more complicated?

This is the reason that David mentions having "a different SONAME",
for the one in local and system, what you say is true for
libraries/frameworks of the same SONAME,
e.g. when building/installing into a system domain, you may link
against a library in the build directory, and then install into the
system directory, if there exists a library in the local directory
which precedes it in the search path, in theory this is okay, because
things with the same SONAME are expected to be compatible.

bundles on the other hand don't have any analogous versioning.
some may be OK


> Another thing comes to my mind. What about the infamous ;) GNUstep.sh which 
> needs to be sourced in ~/.profile : When I install GNUstep in both System and 
> Local, which of the GNUstep.sh do I have to source? Will this possibly break 
> things?

Not sure, suppose it depends on if the GNUstep.sh's are in fact the same.