[crosspost] The state of GNUstep packaging

[Michael Baehr]

Alex went ahead and set up a gnustep-packagers mailing list at
gna.org; list info (including subscription) is available at the
following URL:

https://mail.gna.org/listinfo/gnustep-packagers

Following is my first post to the list.  I was encouraged to crosspost
it to gnustep-discuss and so I have :)  I would appreciate it if you
folks gave it a read, and if anybody who was interested in the state
of GNUstep packaging would subscribe to the new list.

>> Hello GNUstep Packagers

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