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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
