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
Date: Wed, 21 Jul 2004 21:08:37
Message-Id: e0d5beaf244510a480d0e797578ba59a@mudra
2 Hash: SHA1
4 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.
6 Please if any part of this document makes you think about something you did wrong or right as a developer, let me know. Remember, I'm a herd of one, which makes me want to tread carefully, and never make drastic mistakes. Heck, I can't blame anyone, else, you know? ;-) Also, any feedback in general would of course be appreciated. Well, all feedback except that this email is 13K...I know. :-)
8 __Armando Di Cianno aka “fafhrd”
10 RFC: stitching GNUstep into portage
12 * Introduction
14 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 for 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.
16 * Background
18 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.
20 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.
22 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).
24 * Lingo
26 - - “.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”.
27 - - “.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”.
28 - - “.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.
30 * State of Portage
32 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.
34 app-gnustep/gorm
35 app-gnustep/jigs
36 - this is a development library offering a Java bridge
37 app-gnustep/projectcenter
38 - this is a developer application
39 app-gnustep/gridlock
40 app-gnustep/renaissance
41 - this is a development library for gui's
42 app-gnustep/terminal
43 app-gnustep/imageviewer
44 app-gnustep/helpviewer
45 app-gnustep/gworkspace
46 app-gnustep/pantomime
47 - this is a support library for gnumail
48 app-gnustep/gnumail
49 app-gnustep/affiche
50 app-gnustep/talksoup
51 app-gnustep/easydiff
52 + Overall, most entries in this category are applications.
54 dev-libs/ffcall
55 + 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.
57 dev-util/gnustep-back
58 dev-util/gnustep-base
59 dev-util/gnustep-make
60 dev-util/gnustep-gui
61 dev-util/gnustep-guile
62 - unlike the four packages above, this is not a core GNUstep library
63 + 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”.
65 x11-wm/gnustep-env
66 - this is just not a window manager in any way whatsoever
67 + 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.
69 x11-wm/afterstep
70 - only the 1.8.* series of AfterStep depends on x11-wm/gnustep-env, and not the 2.0_beta.
71 + 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.
73 sys-devel/gdb
74 + 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.
76 app-text/dgs
77 + 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.
79 * Planned Portage Layout and Ideas
81 While creating and testing ebuilds, I have been using the following additions and changes to /etc/portage/categories.
83 - - gnustep-base
84 - - gnustep-extra
85 - - app-gnustep
86 - - dev-gnustep
88 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:
90 - - gnustep-make
91 - - gnustep-base
92 - - gnustep-gui
93 - - gnustep-back-art
94 - - gnustep-back-xlib
95 - - gnustep-env
97 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:
99 - - artresources
100 - - cddb.bundle
101 - - cenon-astrology
102 - - cenon-library
103 - - imagekits
104 - - netclasses
105 - - pantomime
106 - - prefsmodule
108 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.
110 The dev-gnustep category is somewhat of a correct ontological categorization, but it contains very few files.
112 - - gorm
113 - - projectcenter
114 - - renaissance
116 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.
118 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.
120 - - aclock
121 - - addresses
122 - - affiche
123 - - calculator
124 - - cdplayer
125 - - cenon
126 - - gnumail
127 - - gworkspace
128 - - helpviewer
129 - - ink
130 - - mixer
131 - - mpdcon
132 - - preferences
133 - - terminal
135 I strongly suggest the retention and use of the app-gnustep category.
137 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.
139 * Portage Conclusions
141 Ideally, I'm imagining this structure for categories in portage:
142 - - app-gnustep
143 - - gnustep-libs
145 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).
147 I find it hard to defend putting applications into what would seem the more appropriate existing portage category for a few reasons:
149 - - 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.
150 - - 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.
152 * ffcall v. libffi considerations
154 Currently, gnustep-base requires the use of a foreign function interface. In short, all this library needs to do is stack frame handling.
156 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.
158 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.
160 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.
162 Version: GnuPG v1.2.4 (GNU/Linux)
163 Comment: Using the GPG bundle for
165 iD8DBQFA/tu5wgiTPLI9xhcRArX6AKCIG+Bie1sMvdNQsPIoOUZyw3r3CwCfUAWs
166 eLZcT+4NhOP/wT6S8UIv8w0=
167 =BGLy
168 -----END PGP SIGNATURE-----
171 --
172 gentoo-dev@g.o mailing list