Re: FHS compliance/Abstraction of NSBundle

[Hubert Chan]

On Mon, 8 May 2006 23:17:50 -0500, Andrew Ruder <address@hidden> said:

[...]

> P.S. I think this will also boost our adoption into distros
> incredibly, GNUstep is not exactly the easiest thing to get into a
> distro due to its non-conformity.

Currently, in Debian, the GNUstep packages "fake" FHS compliance by
using compatibility symlinks.  For example,
/usr/lib/GNUstep/System/Library/Headers is a symlink to
/usr/include/GNUstep/Headers.  This is just done for the System domain
(i.e. packages installed by the Debian packaging system), and is done by
using a script to move the files around after GNUstep Make has installed
them.  It doesn't change anything in the Local, Network, or user
domains.

It's not completely automated, though.  There are some tricky cases --
e.g. sometimes Applications/Foo.app/Resources only includes only
architecture-independent files (e.g. images), and should be moved to
/usr/share.  But sometimes Applications/Foo.app/Resources (I think I've
seen one case) contains an executable or object code, so it has to be in
/usr/lib.  So some of that stuff has to be processed manually.  (In
reality, what usually happens is that the architecture-independent files
are small enough, and they're just left in /usr/lib along with the rest
of the Application bundle.  And nobody has complained yet.)

If anyone is interested in more of the details of what Debian does, let
me know.

Regarding needing to source GNUstep.sh and use openapp, Debian also
provides wrapper scripts that take care of that.

One problem with getting general FHS compliance that I can see is that
the FHS doesn't have anything analogous to the Network or user domains.

-- 
Hubert Chan - email & Jabber: address@hidden - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA