On Wed, Apr 15, 2015 at 4:52 PM, Lars Sonchocky-Helldorf <[email protected]> wrote: > > Am 15.04.2015 um 17:24 schrieb Matt Rice: > >> On Wed, Apr 15, 2015 at 7:48 AM, Matt Rice <[email protected]> wrote: >>> On Wed, Apr 15, 2015 at 12:53 AM, David Chisnall <[email protected]> wrote: >>>> On 14 Apr 2015, at 21:13, Lars Sonchocky-Helldorf >>>> <[email protected]> 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. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
