Hello. Please find attached my new and improved GNUstep environment ebuild for Gentoo, as well as an env.d file, and a runscript. GNUstep is an object oriented application framework, and can be used as a full desktop environment, when coupled with an appropriate window manager, like WindowMaker. I suggest creating support in Gentoo for GNUstep that is completely modernized. Portage directories that should exist are likely: - gnustep-base - gnustep-extra - app-gnustep - dev-gnustep Currently, the extremely aged GNUstep core ebuilds are in dev-util, which is quite inappropriate for them. These should be removed, soon; they can only serve to draw people away from GNUstep and Gentoo in general. Using a model like gnome, kde, and xfce, at least gnustep-base and gnustep-extra should be created. app-gnustep and dev-gnustep offer a solution where those searching portage for GNUstep applications now where to look, while not polluting portage's "namespace" and keeping the gnustep application seperate from others. I will posts links to the other gnustep-base/* new ebuilds as soon as I enter them into the system.
Created attachment 33826 [details] This is the main ebuild for the software package.
Created attachment 33827 [details] This is the env.d file that augments a users own environment setting.
Created attachment 33828 [details] This is the /etc/init.d that starts essential GNUstep system programs at boot time.
Added dependencies for a base GNUstep user environment.
Created attachment 33850 [details] This is an example /etc/portage/categories showing proposed categories usage/changes.
Created attachment 33854 [details] This is an example /usr/local/portage/profiles/use.local.desc for all depended packages on this bug.
Wow, could Gentoo some day have *real* Gnustep support?!? I vote for this!
Lots of discussion can be found in this forum thread: http://forums.gentoo.org/viewtopic.php?t=184040&postdays=0&postorder=asc&start=0 I've tried contacting tseng, who I think is the Desktop goto guy about becoming a developer or generally moving along with this, on both email and IRC, but no luck. Hopefully some dev out there will realize this is important to a many of us out there.
Armando, From what I've heard from solar (one of the gentoo security devs), tseng is off for a week, which is why you haven't been able to contact him. He also left a side note stating that: <solar> gnustep is a security risk sorta as it depends on objc <solar> and objc and pax do not get along Just to give you an idea of the timeline. Great job on getting this going though, as it does appear that it would be a great addition to portage.
Some purely stylistic comments on your ebuild Armando. Some of these apply to all of your ebuilds (or the couple I've checked): o) sys-apps/baselayout is in the default profile - you don't need to list is as depends o) avoid redefining DEPEND and RDEPEND, when one is a subset of another. Use something like RDEPEND="${DEPEND} ... " o) if there is no difference between runtime dependencies (RDEPEND) and compile time (DEPEND) then you don't need to include RDEPEND="${DEPEND}", this is done automatically. o) not a bad idea (not required) do use local <variable name> eg local myconf within functions. o) sometimes it's unavoidable but addwrite should be avoided as a first preference. if there's no other way, that's fine. o) does addwrite /root/GNUstep/Defaults/.GNUstepDefaults.lck work even if the user has "userpriv" in FEATURES? You've done a good job here, and you've done the hardest part, working out the build processes, so with just those few cleanups, these should be good to go. Well done.
Wow, I really appreciate all the feedback I'm getting here, on the forums, and on orkut. I think I've solved the (or one of the) issues with pax and objc. If it's just the libffi over ffcall library choice, then it's done. See bug 54930. Again, thanks for the input and insight, I'm prettying all those ebuilds up now in the ways suggested.
newer package available
