Armando di cia 2012-06-23 22:58:43
My mailer may have corrupted this, I apologize for the resend.
Cheers to first impressions!
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.
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.
__Armando Di Cianno aka fafhrd
RFC: stitching GNUstep into portage
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 bugs.gentoo.org 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.
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.
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 http://www.gnustep.org. 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.
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).
– .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/Foo.app, the installed application resides. It can be launched by running openapp Foo .
– .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 .
– .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.
* State of Portage
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.
– this is a development library offering a Java bridge
– this is a developer application
– this is a development library for gui’s
– this is a support library for gnumail
+ Overall, most entries in this category are applications.
+ 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.
– unlike the four packages above, this is not a core GNUstep library
+ 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 .
– this is just not a window manager in any way whatsoever
+ 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.
– only the 1.8.* series of AfterStep depends on x11-wm/gnustep-env, and not the 2.0_beta.
+ 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.
+ 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.
+ 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 ftp.gnustep.org, 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.
* Planned Portage Layout and Ideas
While creating and testing ebuilds, I have been using the following additions and changes to /etc/portage/categories.
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:
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:
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.
The dev-gnustep category is somewhat of a correct ontological categorization, but it contains very few files.
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.
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.
I strongly suggest the retention and use of the app-gnustep category.
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.
* Portage Conclusions
Ideally, I’m imagining this structure for categories in portage:
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).
I find it hard to defend putting applications into what would seem the more appropriate existing portage category for a few reasons:
– 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/terminal.app ). This method would fully rename the application, something the original authors could take issue with.
– 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.
* ffcall v. libffi considerations
Currently, gnustep-base requires the use of a foreign function interface.. In short, all this library needs to do is stack frame handling.
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.
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.
email@example.com mailing list
Travis tilley 2012-06-23 22:58:56
i’d like for libffi to be the default if possible, since it’s required for
gnustep to work with hardened at all, or on archs like the one i happen to
use. also, isnt ffcall unmainained? —
firstname.lastname@example.org mailing list
Armando di cia 2012-07-01 23:30:50
—–BEGIN PGP SIGNED MESSAGE—–
There’s a good chance that ffcall is, for all intents and purposes,
unmaintained, although people do still regularly use it. Libffi is a
little less “popular”, but for our ends, it is really the only choice.
Sadly, the gcc build process doesn’t compile it unless java and c++
are enabled, but if the target is only “install-target-libffi”, it
only increased the build time from 1 minute to 7, and not to ~35
minutes for the entire gcc w/ java.
Does anyone know if the different arch testing machines available can
host remote X sessions? If so, I really should get in touch with the
maintainer of the amd64 machine, and get to the root of the issues
with the GNUstep core library and amd64. So far, gdb backtraces on
that arch have died in the same function, so I’m crossing my fingers
it remains only that one.
__Armando Di Cianno
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using the GPG bundle for GNUMail.app
—–END PGP SIGNATURE—–
email@example.com mailing list