Note: Please Cc: [EMAIL PROTECTED] in your replies. On Sat, 30 Jul 2005 12:00:32 +0200, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> said:
> Ola Lundqvist <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> - 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
