[gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some)

[gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some)

[Armando Di Cianno]

My mailer may have corrupted this, I apologize for the resend.

Cheers to first impressions!
__fafhrd
--------------------------------------------------------------------------------------------------
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

* Introduction

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.

* Background

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).

* Lingo

- “.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.

app-gnustep/gorm
app-gnustep/jigs
	- this is a development library offering a Java bridge
app-gnustep/projectcenter
	- this is a developer application
app-gnustep/gridlock
app-gnustep/renaissance
	- this is a development library for gui's
app-gnustep/terminal
app-gnustep/imageviewer
app-gnustep/helpviewer
app-gnustep/gworkspace
app-gnustep/pantomime
	- this is a support library for gnumail
app-gnustep/gnumail
app-gnustep/affiche
app-gnustep/talksoup
app-gnustep/easydiff
+ Overall, most entries in this category are applications.

dev-libs/ffcall
+ 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.

dev-util/gnustep-back
dev-util/gnustep-base
dev-util/gnustep-make
dev-util/gnustep-gui
dev-util/gnustep-guile
	- 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”.

x11-wm/gnustep-env
	- 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.

x11-wm/afterstep
	- 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.

sys-devel/gdb
+ 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.

app-text/dgs
+ 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.

- gnustep-base
- gnustep-extra
- app-gnustep
- dev-gnustep

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:

- gnustep-make
- gnustep-base
- gnustep-gui
- gnustep-back-art
- gnustep-back-xlib
- gnustep-env

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
- cddb.bundle
- cenon-astrology
- cenon-library
- imagekits
- netclasses
- pantomime
- prefsmodule

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
- projectcenter
- renaissance

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.

- aclock
- addresses
- affiche
- calculator
- cdplayer
- cenon
- gnumail
- gworkspace
- helpviewer
- ink
- mixer
- mpdcon
- preferences
- terminal

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:
- app-gnustep
- gnustep-libs

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.

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.

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.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some)

[Travis Tilley]

On Wednesday 21 July 2004 05:15 pm, Armando Di Cianno wrote:
> * 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.
>
> 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.
>
> 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.

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?

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: stitching GNUstep into portage (resend: corrupted for some)

[Armando Di Cianno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2004-07-21 19:02:06 -0400 Travis Tilley <lv@gentoo.org> wrote:
> 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?

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

iD8DBQFA/8CFwgiTPLI9xhcRAjxFAJ9q3l3KinQMuqEHFw+RrAxg/z3Q6QCfdY2L
8GaUVIi+GqjxKbDSmMCjes4=
=yCbM
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list