I'm glad this list has finally been set up, and I hope it becomes a useful resource over the next few weeks. I'd like to thank Alex Perez especially for going through the motions of getting this working.
In any case, as far as introduction goes, I am Michael Baehr, a 20-year-old college dropout and GNUstep fanatic. I am currently the maintainer of a 60+ package GNUstep repository for Arch Linux, an i686-optimized BSD-ish GNU/Linux Distribution ( http://archlinux.org ). I have identified a few issues related to GNUstep packaging, and I'd like to lay them out here (there will be some that I have not thought about or forgotten to mention here; your feedback is important): 1) I already mentioned this on gnustep-discuss yesterday. Many GNUstep developers simply do not assume that people will be packaging their software, or at least do not pay much thought to the possibility. There are issues with several pieces of GNUstep software (I can name gnustep-base, gworkspace, and addresses off the bat, though there are more) that make packaging difficult; it seems that the maintainer has assumed in many cases that people will be installing his software directly from source and has done things that break packaging (such as making parts of one package depend on other parts of itself already having been installed). Usually, this can be solved with a little bit of makefile hackery. With gnustep-base, as you'll see, I had to do something quite voodoo to package it properly :D 2) Out-of-date software. There's a rather wide selection of GNUstep software around, but as far as I can tell, only about 60-70% of it is buildable at the present moment, and perhaps 30-40% of it is usable. This is largely due to developers working on a pet project for a little while and then abandoning it. As much as I'd like to have broken apps like CDPlayer, Burn, MusicBox, and others in my repository I have removed them in the interests of quality because they simply do not work. Should we have some people attempt to singlehandedly revive these projects, at least to the point that they work with current GNUstep builds (many of these were abandoned years ago, so they are, needless to say, not easily buildable against current GNUstep libraries)? 3) Daemons/init scripts/whatnot. As far as I can tell, GNUstep apps expect gdomap, gdnc, and gpbs to be running, and also expect you to have sourced the GNUstep.sh init script. On my distribution (Arch Linux), I can easily install an init script in /etc/rc.d and a profile script in /etc/profile.d and expect them to be executed (the init script must be enabled in rc.conf, I digress, but I notify the user of this fact when I install the software). I can thank Arch's BSD-ish init system for this easy installation; however, every distribution differs, and we will need to come up with different ways to make sure that, upon installing GNUstep, a user can expect to have his environment set up and ready. We may be hackers, but we should not expect our users to be. 4) Defaults. There is currently no way to specify defaults on a global level for all users on a system. In order to set up a comfortable environment for people, I like to be able to set up a few keys in NSGlobalDomain that take care of some details. At the moment, I'm working on a gnustep-install script that sets up a GNUstep/ directory in your user directory with a standard set of defaults, but that is not sufficient. This will, unfortunately, require architectural changes. I think this would be essential for some things, though, like theme bundle installation. 5) WindowMaker. How do we treat windowmaker? As of right now, I distribute a windowmaker-cvs build in my tree and at least one of my packages (I believe gnustep-back) depends on it as of the present moment. Because WindowMaker seems to be the only wm at the moment which properly most properly handles the various idiosyncracies of GNUstep applications, I expect my users to be running it. But I really shouldn't. All in all, as a repository maintainer, I feel that I owe it to my users to provide easy, clean installation, and a usable (and good-looking environment) ready for them the instant the packages are installed. I don't want my users to have to be hackers; I want to be the hacker, and let them be the users. It is only this way that we will really spread GNUstep use beyond the tight-knit community that currently uses it. My binary repository is available for Arch users by adding the following to pacman.conf and syncing. [gnustep] Server = ftp://blkwidow.lerp.com/pub/mirror/arch/gnustep GNUstep packages are installable in several different groups. Running `pacman -S gnustep` will install everything. For my fellow packagers, I highly suggest you check out my tree of PKGBUILDS. You will see some of the hacks I have done to get things packaged properly and hopefully will not have to duplicate my effort. Those are available here: http://dely.conio.net/mirror/arch/PKGBUILDS Good day everyone :) -- Michael Baehr
