[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNUstep and FHS



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 <vorlon@debian.org> 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 <hubert@uhoreg.ca> - 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.



Reply to: