Re: FreeBSD GNUstep ports proposal

[Lars Sonchocky-Helldorf]

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? 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?

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?

regards,

        Lars