Gentoo Archives: gentoo-dev

From: Armando Di Cianno <fafhrd@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some)
Date: Wed, 21 Jul 2004 21:13:27
Message-Id: d4b5a2cd8342712ef689e3f63fc85ab0@mudra
1 My mailer may have corrupted this, I apologize for the resend.
3 Cheers to first impressions!
4 __fafhrd
5 --------------------------------------------------------------------------------------------------
6 This follows no RFC style spec ... it's just a request for comments. I especially would like feedback as to how to best lay out and localize GNUstep packages in portage; the section “Planned Portage Layout and Ideas” covers these points. I hope to get feedback from any dev out there who has done something like this before, and any devs that want keep portage's directory structure pretty and readable.
8 Please if any part of this document makes you think about something you did wrong or right as a developer, let me know. Also, any feedback in general would of course be appreciated.
10 __Armando Di Cianno aka “fafhrd”
12 RFC: stitching GNUstep into portage
14 * Introduction
16 Hello everyone. I joined the proud ranks of Gentoo developers a couple weeks ago with the mission to modernize GNUstep on Gentoo. The GNUstep ebuilds currently in portage are rather crufty, and frequently gets "please bump version" new ebuild bugs for GNUstep. This has led to frustration for users, and possible future GNUstep developers. Installation and use of GNUstep on Gentoo should be as easy to get going as KDE or GNOME. While portions of GNUstep itself are still “pre 1.0”, applications based on the GNUstep libraries exist, which many rely on daily.
18 * Background
20 For those that haven't heard the name before, GNUstep is an implementation of the OPENStep specification, that came out of the partnership between NeXT Software, Inc. and Sun circa 1994. Before Apple computers consumed NeXTStep/OPENStep and produced Rhapsody, and then OS X, OPENStep ran on NeXT hardware, x86, sparc, and others (I believe). The desire to have a mature free version of OPENstep sparked the creation of GNUstep.
22 GNUstep, as a project, plans to fully support the OPENStep specification, as well as extend itself to support OS X extensions, as appropriate. More information can be fetched from GNUstep definitely isn't for every user, as it is under somewhat seemingly glacial, but active, development. This is changing somewhat as interest in OS X itself grows.
24 Coupled with the WindowMaker window manager (or others), GNUstep core libraries, and a handful of related applications, a desktop environment can be created that is fairly consistent and useful (although calling GNUstep a DE on gnustep related lists will sometimes result in some amount of correction from some list members, as that is not the goal of the GNUstep Project itself).
26 * Lingo
28 - “.app” – Applications are a collection of code organized in a directory whose name ends with “.app”. Applications all launched by using the “openapp” program (or a graphical tool, like GWorkspace; think “Finder” on OS X). For example: a user installs the Foo application. Then, at /usr/GNUstep/System/Applications/, the installed application resides. It can be launched by running “openapp Foo”.
29 - “.bundle” – Bundles are a collection of data and executable code that Applications can reference and utilize. They install into /usr/GNUstep/System/Library/Bundles, and are named like “Foo.Bundle”.
30 - “.framework” – Frameworks are a collection of library, headers and support files that Applications can build and depend against. They install into /usr/GNUstep/System/Library/Frameworks, and are named like “Foo.Framework”. A framework basically wraps system libraries and headers into a more localized spot, rather than spreading out in places like /usr/lib and /usr/include.
32 * State of Portage
34 This is a list of files in portage that depend on or are part of the GNUstep project. Only package names are shown; all the ebuilds are quite old. Categories, right now, generally are a “best place” for the package, rather than an earnest categorization. Notes have been placed under entries that pretty much are in a non-logical spot.
36 app-gnustep/gorm
37 app-gnustep/jigs
38 - this is a development library offering a Java bridge
39 app-gnustep/projectcenter
40 - this is a developer application
41 app-gnustep/gridlock
42 app-gnustep/renaissance
43 - this is a development library for gui's
44 app-gnustep/terminal
45 app-gnustep/imageviewer
46 app-gnustep/helpviewer
47 app-gnustep/gworkspace
48 app-gnustep/pantomime
49 - this is a support library for gnumail
50 app-gnustep/gnumail
51 app-gnustep/affiche
52 app-gnustep/talksoup
53 app-gnustep/easydiff
54 + Overall, most entries in this category are applications.
56 dev-libs/ffcall
57 + This package is a an option of two, for a required component of “gnustep-base”, and offers a foreign function interface for the library; much discussion about this follows later.
59 dev-util/gnustep-back
60 dev-util/gnustep-base
61 dev-util/gnustep-make
62 dev-util/gnustep-gui
63 dev-util/gnustep-guile
64 - unlike the four packages above, this is not a core GNUstep library
65 + Overall, these four (not counting -guile) packages are core libraries of GNUstep; indeed, in GNUstep CVS, they exist under the “core” directory. Some contain executable support programs, but are in very little way “developer utilities”, like others entries in dev-util, such as “ddd” or “cvs”.
67 x11-wm/gnustep-env
68 - this is just not a window manager in any way whatsoever
69 + Collecting Gentoo support scripts for GNUstep into one package is a good idea, but it relates more to the core GNUstep packages than to a window manager.
71 x11-wm/afterstep
72 - only the 1.8.* series of AfterStep depends on x11-wm/gnustep-env, and not the 2.0_beta.
73 + AfterStep (like WindowMaker) simply instrinsically supports the general GNUstep-like structure of saving defaults, user settings, etceteras. It in no way depends on GNUstep libraries or tools.
75 sys-devel/gdb
76 + Objective-C support is required to compile GNUstep, and to debug GNUstep. Pre-6.0 versions of gdb required special patches; this is no longer the case.
78 app-text/dgs
79 + The Display GhostScript package was going to be the premiere graphical backend for GNUstep, but was dropped a few years ago for development/contracting issues. Many other backends exist for GNUstep, and on X11 based systems, there's at least three at the moment. While located on, this file is not supported by GNUstep, and should not be maintained by the gnustep herd (i.e. me); it has no metadata.xml, so I'm not sure who really cares about it. Packages like ImageMagick still use it, and it may still be of interest for those doing research or development in Display PostScript like technologies.
81 * Planned Portage Layout and Ideas
83 While creating and testing ebuilds, I have been using the following additions and changes to /etc/portage/categories.
85 - gnustep-base
86 - gnustep-extra
87 - app-gnustep
88 - dev-gnustep
90 The addition of gnustep-base and gnustep-extra should be familiar: KDE, GNOME, and XFCE use it, as well as X11 using just an x11-base. Ideally there would be at least a gnustep-base, as there are bona fide core packages from the GNUstep project, as well as a reasonable and good spot for the gnustep-env support package. There are only about 6 packages in this category at the moment, the category is likely not to grow much (possibly by adding new backends), and it includes (these are my new ebuilds being discussed here, now) these packages:
92 - gnustep-make
93 - gnustep-base
94 - gnustep-gui
95 - gnustep-back-art
96 - gnustep-back-xlib
97 - gnustep-env
99 The problem with the gnustep-extra category, that I see, is that there is only one or two true “extra” GNUstep project packages, whereas the rest of the packages are support libraries for packages that currently are in my app-gnustep category. This category, or any sort of “gnustep libraries” category, will likely grow in size greatly. At the moment, it includes the following:
101 - artresources
102 - cddb.bundle
103 - cenon-astrology
104 - cenon-library
105 - imagekits
106 - netclasses
107 - pantomime
108 - prefsmodule
110 ArtResources is required to install the GNUstep Back Art graphical backend, so it is somewhat of a “gnustep-extra” package. NetClasses is useful to create new network applications with, but is not part of the GNUstep project. The rest of the packages are support and extension packages for applications.
112 The dev-gnustep category is somewhat of a correct ontological categorization, but it contains very few files.
114 - gorm
115 - projectcenter
116 - renaissance
118 Gorm and ProjectCenter are GNUstep applications, and could likely go into app-gnustep, if following a GNUstep oriented categorization, or even dev-util. Renaissance is a library, but one that is really only useful to developers and the applications they would write. Possibly it, and many of the packages currently in my “gnustep-extra” belong in a gnustep-libs, as a most appropriate category. Depending on how these packages are categorized, a gnustep-libs category would likely grow in size greatly, whereas gorm and projectcenter are likely to remain the only two main GNUstep IDE-like tools.
120 Finally, the app-gnustep directory. This currently exists in portage, but as stated in the previous section, contains much more than just apps. It is very likely to grow in size greatly.
122 - aclock
123 - addresses
124 - affiche
125 - calculator
126 - cdplayer
127 - cenon
128 - gnumail
129 - gworkspace
130 - helpviewer
131 - ink
132 - mixer
133 - mpdcon
134 - preferences
135 - terminal
137 I strongly suggest the retention and use of the app-gnustep category.
139 Other packages exist that are related to GNUstep, but are out of the scope of this request for comments, as they are standalone projects. The WindowMaker window manager is one such package. At the moment, it's pretty much the only window manager that works acceptably, in my opinion, with GNUstep. There has been discussion recently on GNUstep lists about finally supporting the NET-WM standard for window mangers, which may alleviate this situation. I should note that many run GNUstep with KDE and GNOME, it just doesn't look and feel fully integrated. For this reason, WindowMaker was reparented to the gnustep herd for maintenance, but otherwise, requires no change concerning this document.
141 * Portage Conclusions
143 Ideally, I'm imagining this structure for categories in portage:
144 - app-gnustep
145 - gnustep-libs
147 These two categories fulfill the need to appropriately categorize GNUstep packages, but also do not pollute portage much more (with only the addition of gnustep-libs). All packages which are part of GNUstep core, Gentoo support for GNUstep, misc. bundles, and misc. frameworks, can go there, while all applications can go in app-gnustep (this would include developer app's, too).
149 I find it hard to defend putting applications into what would seem the more appropriate existing portage category for a few reasons:
151 - GNUstep applications tend to have horribly generic names. For example, I think emerging “app-gnustep/terminal” says a lot more to a user than emerging “x11-terms/terminal”. My only other solution for this is to rename all application names (“app-gnustep/terminal”) with .app after them (“x11-terms/”). This method would fully rename the application, something the original authors could take issue with.
152 - GNUstep Applications don't have optional GNUstep support – they are more like “gtk+” and “glib” combined than “gnome” in this comparison. For example, you can compile gAIM without gnome support, but you cannot compile it without gtk+ installed; so, for this reason, putting them in their own categories makes users realize that there's some amount of commitment and mild setup involved in using these apps.
154 * ffcall v. libffi considerations
156 Currently, gnustep-base requires the use of a foreign function interface. In short, all this library needs to do is stack frame handling.
158 Ffcall uses trampolines to do this, and it was quickly pointed out to me by the more security minded dev's that this is a Bad Thing.
160 Sadly, libffi has it's considerations as well. Some years ago, it was basically “parked” inside of GCC. This makes the ebuilds I've written for libffi slightly annoying, in that all GCC sources have to be downloaded; however, I can easily monitor changes to gcc ebuilds, and the libstdc++-v3 ebuild, which I based my libffi ebuilds off of, to maintain the fixes for specific architectures created in those ebuilds.
162 Use of libffi has resulted in full to partial success using (my) GNUstep ebuilds on ppc, sparc, and amd64 as well as x86. Sadly sparc and amd64 need some actual GNUstep core library work, as some misuse of assumptions about word sizes have begun to show themselves.
165 --
166 gentoo-dev@g.o mailing list