В Thu, 16 Sep 2010 10:26:48 -0500, Stef Bidi написа:
> On Thu, Sep 16, 2010 at 8:05 AM, Richard Frith-Macdonald
><r...@gnu.org>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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
