On Mon, 7 Jun 2004 11:25:00 +0800, Sheldon Gill <[EMAIL PROTECTED]> wrote: > > I have a fix for GNUstep-base needing to source GNUstep.sh. It hasn't been > committed to CVS yet but it seems to be coming. My solution also allows for a > somewhat more flexible directory layout. > > I added documentation a while ago to NSTimeZone regarding it's current > behaviour so as to highlight issues for packagers. >
I would like to see this GNUstep.sh fix. The current issue with GNUstep.sh is reliably making sure that everybody's shell sources it, which is a problem when Xterms and many other terminals default to not being login shells (and thus don't source /etc/profile). If you have a solid solution to this that would be wonderful :) > > This is something being worked on, too. For the moment, if you want a global > default on installation you've got to set it at compile time. It's the way it > goes for now. > Well I guess that will have to do for the time being. I do think the eventual solution will involve a global defaults domain, however. I've discussed this problem with a few people and a couple suggested the idea of creating a default GNUstep directory in /etc/skel so that new accounts automatically get a skeleton set of defaults; however, changing them on a global level after the fact obviously is not reflected across those accounts. > > 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. > > Could you write up the hacks you've done and why you've done them that way? > It would make it easier for others to review, rather than having to check out > the tree and go through the source to find out whats what. It would also give > the why which is often not apparent from sources. > I will, when I find the time, as that's not a bad idea. The ones I want to draw specific attention to, in any case, are the PKGBUILD and install file for gnustep-base-cvs, where I use a really dirty hack to get the documentation to build as part of the package and sort out the timezone issue pretty effectively. Some of the things I've done in gworkspace-cvs are useful for showing how to fix broken packages which insist on having parts of them already installed (I understand Enrico has already addressed this issue so I will remove those changes in my next release of gworkspace packages) > It could serve as a good starting point for a Packager's Manual as well. I'd like to see one of these, and I'm gonna talk to Gürkan and Alex (Perez) about putting one together :) > Regards, > Sheldon > It was great hearing your feedback. Thanks for your time, and my regards, Michael Baehr
