PackagingDrafts/GNUstep

= GNUstep Packaging Overview =

This section documents the various GNUstep packaging layouts. The current Fedora layout is contrasted to that used by other distributions, highlighting several issues. The next section discusses the pros and cons of alternative layouts; experienced GNUstep developers and users are invited to participate in this discussion.

What is GNUstep?
(from http://gnustep.org/)

GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components.

Bundles
A characteristic of OpenStep/GNUstep/Mac OS X is that applications are shipped as bundles. Similar to how object-oriented programming combines data and related operations, an application bundle is a directory that contains the binaries associated with an application as well as the application's data files and the metadata required to integrate the application into the desktop.

GNUstep or FHS
Traditionally, GNUstep uses its own filesystem layout, installing everything under. Linux distributions that ship GNUstep packages, however (Debian, openSUSE) package GNUstep using the Unix FHS layout.

"Fat" unflattened layout
When using the traditional GNUstep layout, architecture-dependent files are organized in a tiered layout, for example, an application bundle looks as follows:

hello.app \-- Contents
 * -- Resources
 * -- i386 -- linux-gnu -- gnu-gnu-gnu -- hello
 * -- x86_64 -- linux-gnu -- gnu-gnu-gnu -- hello

This unflattened layout allows for libraries and applications to be shared (for example, on an NFS share) between machines of different architectures, running different operating systems.

Similarly, core binaries and libraries (e.g. from  and  ) are installed under a   hierarchy, allowing for multi-arch binaries and libraries to coexist on the same directory tree.

Flattened layout
When using the Unix FHS layout, GNUstep defaults to using a flat layout: Base binaries are put in  and base libraries in. Note that for RPM multilib distributions such as Fedora and RHEL, the library path would have to be overridden in  to use.

There is a disadvantage to the flattened layout, however: it disables GNUstep's excellent multi-arch support.

Fedora today
Fedora's  currently is configured to use FHS and an unflattened layout. This allows for compliance with the FHS layout used in the rest of the project, while still allowing for application bundles. This configuration, however, is not commonly used, and causes some conflict between GNUstep packages and other Fedora packages that require a discussion of what changes we need to make in our GNUstep packaging.

Using, the following incompatibilities currently exist:


 * Unflattened binaries are put in, conflicting with util-linux-ng, a core Fedora package, in which files with the same name already exist, and are wrappers around.


 * Unflattened libraries are put in . While this does not cause any conflict, it deviates from the Fedora practice of putting libraries in.

Stick with FHS unflattened
This is doable, if we can agree on how to deal with the two problems mentioned above.

Handling binaries
The current Fedora/RHEL handling of binaries on multilib systems is that the binaries from the native arch (e.g. x86_64, ppc64) will override the binaries from a non-native but compatible arch (e.g. i386, ppc). Thus we can simply find all binaries under, and move them to %{_bindir} as part of the package building process.

Placement of libraries
The Fedora guideline is to use. With an unflattened layout, this will result in the 32-bit gnustep-base installing libraries in /usr/lib/i386/linux-gnu/gnu-gnu-gnu and the 64-bit build in /usr/lib64/linux-gnu/gnu-gnu-gnu. Probably not desirable.

Use FHS flattened layout
This is the practice adopted by other Linux distributions, and adheres most closely to the Fedora Packaging Guidelines.

We need to change a couple of things:
 * Patch  to use %{_libdir} instead of %{_prefix}/lib
 * need to search both %{_libdir}/GNUstep/Applications and %{_prefix}/lib/GNUstep/Applications on 64-bit systems

The one downside of this approach is that users who install 32-bit and 64-bit bundles on the same machine would end up with duplicated data files, as the bundles install in orthogonal locations. This is probably not a serious problem in practice, however.