Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac

[Yavor Doganov]

В Thu, 16 Sep 2010 10:26:48 -0500, Stef Bidi написа:
> On Thu, Sep 16, 2010 at 8:05 AM, Richard Frith-Macdonald 
><address@hidden>wrote:
>> The important thing is that things should just work for the naive
>> user who installs from source ... the loader should find their
>> shared libraries, their 'man' command should find the manual pages,
>> their shell should find the executables etc.
>>
> I agree with this statement.  It's a fact that GNUstep doesn't play
> well with the FHS used by, pretty much, every single *nix variant.

Hmm, on Debian at least, everything works with the FHS layout.  If
something doesn't work, it's a Debian bug.  GNUstep Make helpfully
installs a symlink

     /usr/bin/Foo -> /usr/lib/GNUstep/Applications/Foo.app/Foo

so all apps are in $PATH.  Native libraries are installed in /usr/lib,
for frameworks there are symlinks.  Even during the -make 1.x era, it
was still possible to comply with the FHS (we had a
gnustep-app-wrapper and gnustep-tool-wrapper scripts in /usr/bin, and
installed app/tool symlinks programmatically when building the
packages).

> Sourcing GNUstep.sh is fine, but it's not ideal, I consider it a
> work around.

On Debian, it is not necessary to source
/usr/share/GNUstep/Makefiles/GNUstep.sh at all.  I stopped doing this
years ago precisely to catch any eventual bugs and misbehavior.  I
source GNUstep.sh only when I have to try some new app which is not
packaged, in which case I install it with
GNUSTEP_INSTALLATION_DOMAIN=USER.

> Back when I was somewhat maintaining the SlackBuild scripts for
> GNUstep I simply passed --with-filesystem-layout=fhs.  Again, this
> is fine but I still just consider it a work around.  Like Richard, I
> think GNUstep should be installed where to the native layout to
> begin with.

Well, I admit I'm not an FHS fan [1], but for those who have never
used NEXTSTEP and/or Muck OS, the GNUstep layout is completely alien.

So I don't blame Debian for trying to keep their system consistent.
There are lots of programs/subsystems with their own, completely
different views of the world (think of Ruby gems, or web apps), so
from the user/sysadmin POV having a consistent system instead of
incoherent mess is a big plus.

[1] I find some decisions awkward, for example the lack of
    /usr/libexec.