[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Packaging GNUstep & DFSG



I've started packaging our current GNUstep developer snapshots and ran into several problems regarding DFSG and FSSTND.

GNUstep is an FSF effort on a free implementation of the OpenStep specification (see http://www.gnustep.org). The OpenStep specification contains three components: FoundationKit (ObjC base classes), AppKit (an ObjC GUI framework built on top of FK and DPS) and Display Postscript.

Most parts of the project are currently only available as developer releases or snapshots; their degree of completion ranges between 80% (Foundation) and 30% (AppKit). 

This is work in progress that's not meant for use on production machines, still the API is fixed and therefore the interfaces changes will be minimal in the future.

Currently, there's a dependence on a Display Ghostscript package that's based on the non-free gs-aladdin 4.03; a GPLed DGS will be released in the next three months. See below for a detailed description.

IMHO Debian packages of the developer snapshots might be interesting for `early adoptors' as well as GNUstep volunteers.


But where do the packages go, and for what reasons ?

- gstep-* in contrib and dgs-aladdin in non-free ?
- gstep-* in experimental and dgs-aladdin in non-free ?
- all in experimental ?
- gstep-* in main and dgs-aladdin in non-free ?

I could make up arguments for all of those.



Furthermore, I'm not sure if the GNUstep file layout is FSSTND compliant. Like KDE (?), GNUstep defines a hierarchy of its own in a GNUSTEP_SYSTEM_ROOT subtree. Headers, shared+static libraries, apps and tools go into this subtree. GNUstep applications will be started with a separate command, openapp, that correctly sets LD_LIBRARY_PATH. For a detailed description of the directory layout, see below.

I see no easy way to map this to the traditional FSSTND, still I'm not decided on which points this really contradicts the FSSTND. Could somebody comment here ?

	Gregor

---
| Gregor Hoffleit     admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut   PHONE: (49)6221 56-5771 |
|       INF 288, 69120 Heidelberg / Germany  FAX: 56-3812 |
| EMAIL: flight@mathi.uni-heidelberg.de (NeXTmail)        |




The GNUstep copyright and dependency issues
-------------------------------------------

GNUstep maps the Kit defined in OpenStep as follows:

- FoundationKit: gnustep-base
- AppKit: gnustep-gui and gnustep-xdps: gnustep-gui is a device-independent frontend, while gnustep-xdps is a backend that uses X11/DPS as its output device.
- Display Postscript: an enhanced version of Ghostscript (DGS), and the free X11 DPSclient libraries by Adobe.

Future issues: GNUstep has contracted Aladdin Software to implement the necessary changes to Ghostscript; the contract insures that a GPL version of DGS will be available.

Besides the official xdps backend, other backends for gnustep-gui are worked on. There's a backend for win32, and a backend for X11 without DPS is worked on.

Programs using gnustep-gui with the xdps backend also have to be linked with the DPSclient libs. To be run, they need to connect to an DPS server; DGS is one implementation of an DPS server.

All contributions of the GNUstep project are copyrighted by the FSF and GPL'd. The DPSclient library is copyright Adobe, but free to the terms of the DSFG.

DGS is currently built on top of Aladdin Ghostscript 4.03, which is not free to the terms of the DSFG. [Aladdin Ghostscript was released in Sep 96 and will be rereleased as GNU Ghostscript approximately a year after.]







The GNUstep Directory structure
===================

There are several directories used in a GNUstep environment. The
directories are relative to a top directory whose name is given by the
variable GNUSTEP_SYSTEM_ROOT ($GNUSTEP_SYSTEM_ROOT in a shell or
$(GNUSTEP_SYSTEM_ROOT) in a makefile). Below is the hierarchy of
GNUstep directories:

$(GNUSTEP_SYSTEM_ROOT)/
    Headers/
    Libraries/
    Apps/
    Tools/

The Headers/ and Libraries/ directories, as their names suggest, keep
the header files and the libraries required by a GNUstep project to
compile and link. The libraries can be both shared or static,
depending on the target system.

The Apps/ directory is used by GNUstep graphical applications, those
applications which have a graphical interface with the user. The
Tools/ directory holds command line tools based on GNUstep libraries.

The header files are grouped like this in the Headers/ directory:

Headers/
  gnustep/
    base/
    Foundation -> base
    gui/
    AppKit -> gui
  libFoundation/
    Foundation/

The Libraries/ directory can hold libraries for several machines and
several combinations of packages:

Libraries/
  i386/
    linux-gnu/
      gnu-gnu-gnu-xdps/
	libgnustep-base.so
	libgnustep-gui.so
	libgnustep-xdps.so
      gnu-fd-gnu-xdps/
	libFoundation.so
	libgnustep-gui.so
	libgnustep-xdps.so
  sparc/
    solaris-2.5.1/
      nx-pdo-gnu-xdps/
	libgnustep-gui.so
	libgnustep-xdps.so

Please note that the Libraries/ directory contains only the libraries
that come with GNUstep, the PDO library for example is not inside
Libraries/. The compiler has to know where that library can be found,
although the makefile package is responsible for passing all the
necessary flags during compiling and linking.

The libraries directory also contains resource files which belong to
the GNUstep libraries, such as images and printer description
files. Since the images can look different for different backends,
each backend has its own images in a different directory based upon
the interface look and feel:

Libraries/
  Resources/
    Images/
      NeXT/
      Win32/
    PrinterTypes/
    Fonts/
    gnustep/
	NSCharacterSets/
    libFoundation/
      CharacterSets/
      Defaults/
      TimeZoneInfo/

The resources that are specific to each Foundation libraries are kept
in a subdirectory like above, except for NeXT Foundation and PDO which
keep their resources in their own places.

The Apps/ directory contains GNUstep graphical applications. Each
application is kept in an app wrapper which contains all the binaries
and all the resource files the application needs. The binaries
organization resembles the one from libraries:

Apps/
  InterfaceModeller.app/
    InterfaceModeller (for OPENSTEP systems compatibility)
    i386/
      linux-gnu/
	gnu-gnu-gnu-xdps/
	  InterfaceModeller
    sparc/
      solaris-2.5.1/
	nx-pdo-gnu-xdps/
	  InterfaceModeller

The Tools/ directory contains command line tools.  Each tool
executable is placed in a subdirectory corresponding to the CPU and
operating system.

Tools/
  i386/
    linux-gnu/
	autoconf
	gcc
	dgs
  sparc/
    solaris-2.5.1/
	autoconf
	gcc


Reply to: