Hi all, I've done some work on making the GNUstep core packages more FHS compliant, and I'd like some input to make sure that I have addressed all complaints. If no other complaints are raised, I will assume that the GNUstep packages are fit for release -- at least in terms of complying with the FHS.
On Tue, 2 Aug 2005 23:57:10 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > FWIW, I don't think /usr/share vs. /usr/lib is the biggest issue in > GNUstep. Well, I've worked on fixing that anyways. All the main arch-indep directories under the GNUstep tree have been moved to /usr/share/GNUstep, and I've added symlinks from the old /usr/lib locations to the new /usr/share locations so that the GNUstep applications can find them properly. > I think the bigger issues are: > - shared libs in /usr/lib/GNUstep/foo instead of in /usr/lib (has been > done by other packages in the past, but it looks like my historical > example, mozilla, has been cleaned up) All the core GNUstep libraries are now in /usr/lib instead of /usr/lib/GNUstep/System/... . (Again, compatibility symlinks from the old locations are added.) The framework libraries are still kept in /usr/lib/GNUstep/System/Frameworks/foo.framework/..., though. My gut feeling is that it would be a mistake to move those, since GNUstep frameworks have their own versioning system (due to its OpenStep heritage). However, I've added symlinks from /usr/lib. (Of course, the location of framework libraries doesn't affect the core packages, so this point could be argued at a later time without affecting the core.) The end result is that ld.so.conf doesn't need to be modified; all libraries can be found within /usr/lib. > - ObjC headers in /usr/lib/GNUstep/bar instead of in /usr/include; > it's not clear whether this is actually an FHS violation, since the > FHS says C/C++... :) All headers are now in /usr/include/GNUstep. The main header directory is /usr/include/GNUstep/Headers, and the framework headers get relocated to /usr/include/GNUstep/Frameworks/foo.framework/... > - manpages apparently duplicated under > /usr/lib/GNUstep/System/Library/Documentation/man/manX/ /usr/lib/GNUstep/System/Library/Documentation/man is now a symlink to /usr/share/man. (Same with /usr/lib/GNUstep/.../Documentation/info). > - user-executable binaries under /usr/lib/GNUstep/baz instead of in > /usr/bin Application binaries are still under /usr/lib/GNUstep/System/Application/foo.app/foo. However, these are not intended to be executed directly. All GNUstep applications have helper scripts that are in /usr/bin. (Similar to the mozilla helper script.) The GNUstep.sh and GNUstep.csh scripts, for setting up the environment, are still in /usr/lib/GNUstep/... . However: - these are not technically needed any more, since GNUstep doesn't depend on the environment variables any more. (The only useful environment variable is GNUSTEP_PATHLIST, plus maybe the Guile and Java search paths.) - these should not be in /usr/bin, since they need to be sourced, and not executed, since they need to set environment variables. .deb packages that reflect those changes can be found at: http://www.uhoreg.ca/programming/debian/gnustep/packages/ (apt-gettable -- but beware: installing these packages will cause all old GNUstep applications to be uninstalled, due to the incompatible changes) Listings of all the packages can be found at: http://www.uhoreg.ca/programming/debian/gnustep/ (links at the bottom half of the page) Let me know if I have missed anyone's complaint about the GNUstep packages, but I think that Steve's list was fairly complete. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
