Re: Another thought about GNUSTEP_INSTALLATION_DOMAIN

[Adrian Robert]

On Oct 13, 2006, at 5:09 AM, Richard Frith-Macdonald wrote:

> On 13 Oct 2006, at 09:32, Richard Frith-Macdonald wrote:
>
> > It occurs to me that NSSearchPathForDirectoriesInDomains() has a  
> > mask of domains as the second argument.
> > That means that code looking for resources is expected to know  
> > which domain it should be finding them in ... rather than just  
> > looking in all domains.
> > So there is an inbuilt assumption supported by the API that  
> > certain packages are installed in certain domains.
> >
> > We could go through all code and make sure that whenever  
> > NSSearchPathForDirectoriesInDomains() is used, its second argument  
> > is the mask of all domains ... so that it should work wherever  
> > packages are installed.
> > The downsides of that are ...
> > 1. we don't control all the code using that function
> > 2. it may not be a good idea to load some resources from some  
> > domains (eg security)
> >
> > However, we could just say
> > 1. it's the programmers fault if they depend on a resource in a  
> > particular location, and well written code should cope
> > 2. security issues should be addressed independently anyway
> >
> > But if we do that I think we need to document it very clearly.
>
> Searching through the base library I see that it currently expects  
> to find the SSL bundle, the gdomap nameserver executable, the gdnc  
> notifcation server executable and system documentation projects in  
> the System domain.
>
> So, as it currently stands, gnustep-base would *mostly* work if  
> installed in a non-System domain, but not entirely.


I'm getting a bit confused trying to follow this thread.  I thought  
the original desire was simply to allow GNUstep libs in locations  
like /usr/lib and resources in /usr/share, etc..  The use of the term  
"GNUSTEP_INSTALLATION_DOMAIN" confused the issue by being unclear  
about whether GNUstep's internal map (System, Local, User domains) or  
the external situation on Unix installations (/usr, /opt, etc.) was  
referred to.  So please pardon me if the next paragraph is off  
(hopefully not).

IMHO GNUstep is already beyond the point where changes that  
significantly affect what is seen internally by GNUstep programs  
should be considered.  Base is post-1.0, and there are a lot of  
applications out there.  If you want to tweak where GNUstep resources  
are installed on the host filesystem, that is one thing.  Making  
internal changes that enhance code compatibility with OS X is worth  
consideration as well, but suddenly requiring programs to search  
everywhere for what were formerly system resources, simply to make  
installation cleaner on one type of deployment platform (that not  
everyone thinks is the most important in the long run for GNUstep) is  
a bad thing.

It was difficult enough adapting to the round of changes when  
GNUstep.conf was introduced, and I daresay there is still confusion  
amongst app developers as to the respective roles of GNUstep.conf and  
GNUstep.[c]sh.  While the benefits of FHS installation are nonzero,  
the amount of initial disruption and any possible divergence in OS X  
compatibility should be carefully considered.

Also, I suggest that an explicit policy for what goes in System  
domain for GNUstep be developed, following as closely as possible  
what OS X does.