Re: FHS filesystem layout issues [was: Re: Request for update and/or release of GDL2 and Renaissance]

[Richard Frith-Macdonald]

On 30 Jan 2014, at 19:58, Niels Grewe <niels.grewe@halbordnung.de> wrote:

> 
> Am 30.01.2014 um 18:25 schrieb Markus Hitter <mah@jump-ing.de>:
> 

> There’s a well known phrase coined by the philosopher Neil Wilson called the 
> ‘principle of charity’. It means that you should always assume the most 
> favourable interpretation of another person’s behaviour. In this spirit, I’d 
> like you to consider that maybe people are not trying to be difficult on 
> purpose. Maybe they just didn’t understand what you were trying to tell them. 
> At least it was this way with the make documentation issue for me: I 
> wholeheartedly admit that it took a few days before it dawned to me what the 
> bug report was trying to say (Note I’m not saying that that’s your fault, 
> sometimes I’m just slow on uptake or not diligent enough while reading). In 
> such cases, anything but a polite re-explanation just furthers 
> misunderstanding and hostility, which doesn’t help anybody. (I also apologise 
> if this sounds patronising, but I just want to make sure that you know on 
> what basis I’d like to discuss this) 

Well said.

> Just as with NSBundle, the different domains are part of the OpenStep/Cocoa 
> APIs. Why do you think it would be possible to just remove them? I don’t see 
> the need to to do that either. What’s nice about domains is that they are 
> more like logical locations than paths on the filesystem (as prefixes would 
> be). Having said that, they still can be mapped nicely to directories within 
> the FHS space (with the exception of the network domain):
> 
> * Directories from the system domain are mapped to suitable directories below 
> /usr
> * Directories from the local domain are mapped to suitable directories below 
> /usr/local
> * Directories from the user domain are mapped to suitable directories in 
> /home (the xdg basedir specification can give some hints on this, but it 
> doesn’t provide a complete solution, my feeling is that most stuff would live 
> below /home/${username}/.local/ )
> 
> So basically, packaged GNUstep stuff is installed into the system domain, 
> shared self-compiled stuff goes into the local domain, and if you are 
> building things just for yourself, you install them into the user domain.

Yes, as you say, the FHS does include the notion of domains similar to 
OpenStep/Cocoa.  There's no equivalent to the network domain, but that's hardly 
ever used anyway (and can easily be mapped to the system domain or the local 
domain).

>> Essentially this means:
>> 
>> - There are only two kinds of (supported) filesystem layouts, FHS and
>> bundle-type. The other ones are obfuscating clutter.
> 
> 1. ‘bundle-type’ is not a filesystem layout. To which are you referring?

Agreed ... but I think I see where Marcus is coming from here.
I've had a chat with debian mentors, and come away with a few key points.

1. My reading of the FHS spec had been that private resources were really not 
covered; in fact private resources are expected to be in /usr/share (yes, 
'share' includes private) and /usr/lib, but in subdirectories (so a bundle can 
in principle just be a subdirectory there).
2. The resources have to be split upon architecture dependency lines ... ie 
architecture dependent stuff has to go in 'lib' and architecture independent 
stuff in 'share'.
This is probably where the FHS vs Bundles idea comes from ... a bundle might 
well contain both types of resource, but FHS wants to split them up.

I suppose we could pretend all resources are architecture dependent and put 
bundles entirely in 'lib' rather than 'share', and it might technically satisfy 
Debian policies.  However, that's rather ugly (an abuse of the system really).
A better solution would be to extend gnustep-make and gnustep-base to support 
the separation, extending the existing filesystem layout code to be a little 
more fine-grained;
A setting in GNUstep.conf would control what separation is required.
gnustep-make would create (and install into) separate bundle directories for 
architecture dependent and non-architecture dependent resources.
gnustep-base would search both places when looking up a resource.

I imagine gnustep-make could be modified to automatically do this for code 
bundles (ie put the dynamically loadable code in a subdirectory in lib), while 
continuing to put other resource bundles in share.
But, we would probably need user-visible changes to let a developer specify 
other architecture dependent resources (though I guess those are rare).