[Debian GNUstep maintainers] Re: GNUstep and FHS

[Hubert Chan]

Note: Please Cc: pkg-gnustep-maintainers at lists.alioth.debian.org in your
replies.

On Sat, 30 Jul 2005 12:00:32 +0200, Marc 'HE' Brockschmidt <he at debian.org> said:

> Ola Lundqvist <opal at debian.org> writes:
>> I do not really see a problem here. All gnustep packages store files
>> in a (at least sort of) FHS compliant directory: /usr/lib/GNUstep

> Are the files stored there only object files, libraries and internal
> binaries not intended to be executed directly by users? [This is
> quoted From the FHS]

No.  Here's a brief tour of the GNUstep hierarchy for those who are
unfamiliar with it.  Before that, though, I should note that this
hierarchy is the way that it is not because upstream is trying to be
difficult, but because it is emulating the NeXT/OpenStep hierarchy
(which is also used by MacOS X).  Since GNUstep is intended to implement
the OpenStep standard, it is only natural to adopt that hierarchy.

Currently, under /usr/lib/GNUstep/System, we have:

.../Tools: only contains binaries, not intended to be executed directly
  by users, but rather via the opentool program, so this directory
  should be fine according to the FHS.

.../Library: contains several subdirectories.  Some, such as
  Library/Libraries only contain libraries, and so are fine under FHS.
  Some, such as Library/Images or Library/Sounds are completely
  arch-independent.  Directories such as those I think can be moved to,
  say, /usr/share/GNUstep, and we can use a symlink so that GNUstep
  programs can find the data.  (Eric would be more familiar with this
  than I am.)  However, some directories such as Library/Bundles and
  Library/Frameworks contain a mix of arch-dependent and
  arch-independent files, that don't seem to be very easy to separate
  (see below).

.../Library/Bundles: Bundles (similar to plugins) are directories that
  contain binaries that are used by applications, as well as all the
  data required for the binary to run (resources, information about the
  bundle, i18n data, etc.).  Some of that stuff seems to be in a similar
  situation to what Colin mentioned with the Perl modules in
  /usr/lib/perl [2] -- even though it's technically arch-independent,
  it's so tightly tied to the binary that if it was put into /usr/share,
  and /usr/share was NFS-mounted, then every computer using the same NFS
  mount would need to have the same version of the binary.

[1] I'm not familiar enough to say how much falls into this category.
  At least the "information about the bundle", I think, falls into this
  category.
[2] http://lists.debian.org/debian-policy/2005/07/msg00125.html

.../Library/Services: similar situation to Library/Bundles.

.../Library/Frameworks: Frameworks are directories that contain
  libraries, their header files, and data needed for the library to run.  So
  they are similar to Bundles in the sense that they mix arch-dependent
  and independent files, but those files are fairly closely related.

.../Applications: Contains directories named <appname>.app which
  contain, well, applications.  These directories include binaries and
  the data required for them to run.  Even though the executables
  reside in these directories, they are not intended to be run directly,
  but rather through the openapp program.  The GNUstep packages in
  Debian also contain a wrapper script in /usr/bin.  So at least that
  part shouldn't cause a problem with the FHS.  Now, again, the
  <appname>.app directories contain both the binary, and the data
  required for the binary to run, similar to the data contained within
  the bundles.

Also, I should note that one of the reasons Bundles, Services,
Frameworks, and Applications are laid out in this way is that on
OpenStep platforms, it is intended that you should be able to just cp a
single directory from one computer to another computer (of the same
architecture, obviously), and be able to use that
Bundle/Service/Framework/Application as-is.  This is one of the features
of OpenStep, so it would be nice if any attempt to make GNUstep more
FHS-compliant didn't break this ability.

-- 
Hubert Chan <hubert at uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.