Re: [RFA}: Filesystem update for gnustep-make

[Stefan Urbanek]

On 2003-04-05 18:54:13 +0200 Adam Fedor <fedor@doc.com> wrote:

<snip>

> I think ScriptKit is a general enough, system-wide framework that it could 
> probably go in Library. But I think you should design the package so that it 
> would be easy for someone to move it if they desired.

Probably you meant StepTalk, ScriptKit is from gnustep-guile.
To make it easier to relocate I should convert it from library to a framework 
and to pack all standard bundles into that framework. I was mainly asking about 
those directories, because users can put their own extensions (bundles, 
languages,...) there. I am not sure how are frameworks supported on other 
systems. I would prefer that framework solution.

> In fact, what I'd mostly like to do with this FSH change, even if we end up not 
> changing the structure around at all, is to make it easy for someone who is, 
> say, making a complete GNUstep distribution, to trivially patch and/or 
> configure GNUstep to put the directories where they want them to be (within 
> reason, of course).

Well, I think that it is good intention to leave freedom of gnustep placement. 
On the other hand, I think that only placement freedom should be in placing 
gnustep System/Local/Network/User domain directories. I see gnustep as single 
integrated environment (approximate analogy should be mozilla, openoffice and 
possibly emacs), not as a bunch of yet another libraries and tools. This is 
also the reason why I do not like that debian gnustep displacement (and i see 
no reason for making lowercase links/wrappers for gnustep applications in 
*/bin) . gnustep apps are part of gnustep, not hosting OS, same for docs, 
frameworks, libraries,... I doubt that someone will use gnustep libraries for 
non-gnustep project (and if yes, it will be a rare exception). All that stuff 
is making integrated environment.
To be more specific, on gnustep installation one should chose only directories 
for gnustep domains. Besides other simplifications, this will make easier for 
anyone to adapt any other gnustep installation.  The simpliest case of gnustep 
installation should be unarchiving some gnustep-environment.tar.gz (or .exe) 
containing all domains into for example /usr/GNUstep. For systems with package 
management i think that domain consistency should be maintained. Even in this 
case think, that there should be separate gnustep package management that will 
allow installation of gnustep packages into specific domains (like user), not 
just System, as it is done with default OS package managers.

It is just my point of view and as i have mentioned, i see gnustep as:
   Standalone *integrated* environment with interacting applications, 
distributed objects and tools.

Best regards,

Stefan Urbanek