From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18915 invoked from network); 21 Jul 2004 21:08:37 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 21:08:37 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnOKI-0000NA-Ip for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 21:08:34 +0000 Received: (qmail 14250 invoked by uid 89); 21 Jul 2004 21:08:33 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 587 invoked from network); 21 Jul 2004 21:08:33 +0000 Date: Wed, 21 Jul 2004 17:10:18 -0400 Message-ID: MIME-Version: 1.0 (Generated by Pantomime 1.2.0) From: Armando Di Cianno To: gentoo-dev@lists.gentoo.org X-Image-URL: http://armando.xylite.com/images/me64x64.tiff X-Mailer: GNUMail.app (Version 1.2.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1250" Subject: [gentoo-dev] RFC: stitching GNUstep into portage X-Archives-Salt: b40f62a2-c0dd-4a48-8c9f-b64254d53a74 X-Archives-Hash: 8b34f37b9568491e7d44b86c1f0f1cb8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 GN= Ustep packages in portage; the section =93Planned Portage Layout and Ide= as=94 covers these points. I hope to get feedback from any dev out ther= e who has done something like this before, and any devs that want keep p= ortage'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. Remember, I'm a herd of= one, which makes me want to tread carefully, and never make drastic mis= takes. Heck, I can't blame anyone, else, you know? ;-) Also, any feedb= ack in general would of course be appreciated. Well, all feedback excep= t that this email is 13K...I know. :-) __Armando Di Cianno aka =93fafhrd=94 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 freq= uently gets "please bump version" new ebuild bugs for GNUstep. This has= led to frustration for users, and for possible future GNUstep developer= s. Installation and use of GNUstep on Gentoo should be as easy to get g= oing as KDE or GNOME. While portions of GNUstep itself are still =93pre= 1.0=94, applications based on the GNUstep libraries exist, which many r= ely on daily. * Background For those that haven't heard the name before, GNUstep is an implementati= on of the OPENStep specification, that came out of the partnership betwe= en NeXT Software, Inc. and Sun circa 1994. Before Apple computers consu= med NeXTStep/OPENStep and produced Rhapsody, and then OS X, OPENStep ran= on NeXT hardware, x86, sparc, and others (I believe). The desire to ha= ve 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 de= finitely 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.=20 Coupled with the WindowMaker window manager (or others), GNUstep core li= braries, and a handful of related applications, a desktop environment ca= n be created that is fairly consistent and useful (although calling GNUs= tep a DE on gnustep related lists will sometimes result in some amount o= f correction from some list members, as that is not the goal of the GNUs= tep Project itself). * Lingo - - =93.app=94 =96 Applications are a collection of code organized in a = directory whose name ends with =93.app=94. Applications all launched by= using the =93openapp=94 program (or a graphical tool, like GWorkspace; = think =93Finder=94 on OS X). For example: a user installs the Foo appli= cation. Then, at /usr/GNUstep/System/Applications/Foo.app, the installe= d application resides. It can be launched by running =93openapp Foo=94.= - - =93.bundle=94 =96 Bundles are a collection of data and executable co= de that Applications can reference and utilize. They install into /usr/= GNUstep/System/Library/Bundles, and are named like =93Foo.Bundle=94. - - =93.framework=94 =96 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= =93Foo.Framework=94. 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 GNU= step project. Only package names are shown; all the ebuilds are quite o= ld. Categories, right now, generally are a =93best place=94 for the pac= kage, rather than an earnest categorization. Notes have been placed und= er 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 =93gnu= step-base=94, and offers a foreign function interface for the library; m= uch 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 =93core=94 dire= ctory. Some contain executable support programs, but are in very little= way =93developer utilities=94, like others entries in dev-util, such as= =93ddd=94 or =93cvs=94. 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 go= od idea, but it relates more to the core GNUstep packages than to a wind= ow 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 genera= l 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 GNUst= ep. 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/co= ntracting issues. Many other backends exist for GNUstep, and on X11 bas= ed 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 ma= intained by the gnustep herd (i.e. me); it has no metadata.xml, so I'm n= ot sure who really cares about it. Packages like ImageMagick still use = it, and it may still be of interest for those doing research or developm= ent in Display PostScript like technologies. * Planned Portage Layout and Ideas While creating and testing ebuilds, I have been using the following addi= tions 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 pack= ages 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 th= is category at the moment, the category is likely not to grow much (poss= ibly 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 i= s only one or two true =93extra=94 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 =93gnuste= p libraries=94 category, will likely grow in size greatly. At the momen= t, 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 backe= nd, so it is somewhat of a =93gnustep-extra=94 package. NetClasses is u= seful to create new network applications with, but is not part of the GN= Ustep project. The rest of the packages are support and extension packa= ges for applications. The dev-gnustep category is somewhat of a correct ontological categoriza= tion, but it contains very few files. - - gorm - - projectcenter - - renaissance Gorm and ProjectCenter are GNUstep applications, and could likely go int= o app-gnustep, if following a GNUstep oriented categorization, or even d= ev-util. Renaissance is a library, but one that is really only useful t= o developers and the applications they would write. Possibly it, and ma= ny of the packages currently in my =93gnustep-extra=94 belong in a gnust= ep-libs, as a most appropriate category. Depending on how these package= s are categorized, a gnustep-libs category would likely grow in size gre= atly, whereas gorm and projectcenter are likely to remain the only two m= ain GNUstep IDE-like tools. Finally, the app-gnustep directory. This currently exists in portage, b= ut 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 sco= pe of this request for comments, as they are standalone projects. The W= indowMaker window manager is one such package. At the moment, it's pret= ty much the only window manager that works acceptably, in my opinion, wi= th GNUstep. There has been discussion recently on GNUstep lists about f= inally supporting the NET-WM standard for window mangers, which may alle= viate 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 oth= erwise, 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 GNUste= p packages, but also do not pollute portage much more (with only the add= ition of gnustep-libs). All packages which are part of GNUstep core, Ge= ntoo support for GNUstep, misc. bundles, and misc. frameworks, can go th= ere, while all applications can go in app-gnustep (this would include de= veloper app's, too). I find it hard to defend putting applications into what would seem the m= ore appropriate existing portage category for a few reasons: - - GNUstep applications tend to have horribly generic names. For examp= le, I think emerging =93app-gnustep/terminal=94 says a lot more to a use= r than emerging =93x11-terms/terminal=94. My only other solution for th= is is to rename all application names (=93app-gnustep/terminal=94) with = .app after them (=93x11-terms/terminal.app=94). This method would fully= rename the application, something the original authors could take issue= with. - - GNUstep Applications don't have optional GNUstep support =96 they ar= e more like =93gtk+=94 and =93glib=94 combined than =93gnome=94 in this = comparison. For example, you can compile gAIM without gnome support, bu= t you cannot compile it without gtk+ installed; so, for this reason, put= ting 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 b= asically =93parked=94 inside of GCC. This makes the ebuilds I've writte= n for libffi slightly annoying, in that all GCC sources have to be downl= oaded; however, I can easily monitor changes to gcc ebuilds, and the lib= stdc++-v3 ebuild, which I based my libffi ebuilds off of, to maintain th= e 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 assumptio= ns about word sizes have begun to show themselves. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using the GPG bundle for GNUMail.app iD8DBQFA/tu5wgiTPLI9xhcRArX6AKCIG+Bie1sMvdNQsPIoOUZyw3r3CwCfUAWs eLZcT+4NhOP/wT6S8UIv8w0=3D =3DBGLy -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list