Re: Packaging GNUstep & DFSG
On Mon, 10 Nov 1997, Gregor Hoffleit wrote:
> 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 ?
AFAICS (please correct me if I'm wrong) the non-free dgs-aladdin is
currrently the only available backend. All the rest is DFSG free, right?
(As soon as a free backend comes available things will change.)
> - gstep-* in contrib and dgs-aladdin in non-free ?
> - gstep-* in experimental and dgs-aladdin in non-free ?
> - all in experimental ?
All three solutions are ok. However, I'd either choose the first or the
third solution.
Is gnustep useful (at least for some people) already? If so, I suggest
that you choose the first solution. If it's just very alpha and only
intresting for a few GNUstep hackers I suggest you put everything in
experimental.
(We don't have any copyright/license restrictions for experimental,
AFAIK.)
> - gstep-* in main and dgs-aladdin in non-free ?
No, this isn't allowed by policy, since gstep-* will depend on
dgs-aladdin.
However, if some day a free "dgs-x11" (or whatever) becomes available, you
could change the "dgs-*" packages to provide "dgs" or similar (note, that
this would need a discussion on debian-devel), have dgs-* provide
dgs, and gstep-* depend on "dgs". With that setup, "gstep-*" and "dgs-x11"
could be in "main" and "dgs-aladdin" in "non-free" (unless it became free
at that time).
[snip]
> 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 ?
Sorry, but I think you'll have to "hack" the GNUstep sources in order to
install into the correct locations. (I.e., you'll have to split up the
files into several directories.)
As long as the path names are not hardcoded into all binaries you might
consider installing everything into debian/tmp/foo/... at package build
time and move the files into different packages/directories within the
debian/rules script.
You might also want to contact Andreas Jellinghaus (maintainer of KDE
packages). Perhaps he knows some tricks how to do this easily :-)
I hope this answers your questions. If you have additional questions, feel
free to contact me and/or the mailing list again and we'll try to answer a
bit faster :-)
Thanks,
Chris
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian is looking schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
for a logo! Have a
look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/
Reply to: