Hi,
On Sat, Aug 23, 2008 at 02:03:23PM -0400, Michel Salim wrote:
What
===
GNUstep is a Obj-C-based framework, similar to Mac OS X's Cocoa
State of GNUstep in Fedora
================
GNUstep has long been excluded from Fedora due to its non-standard
filesystem layout. Recently, however, its support for being installed
under the FHS layout has improved. gnustep-make is now in Fedora.
There are some problems with the current layout used by Fedora; see
below.
Other distributions
===========
Debian and its derived distributions have the complete GNUstep stack
already packaged. The file system layout they adopted seem to be a
flattened FHS layout.
Current problems
==========
OpenStep/GNUstep/Cocoa allow for application bundles: self-contained
directories that is treated by the application launcher (openapp in
GNUstep) as applications. In GNUstep terminology, a "flattened"
layout, such as used in Debian, makes the application bundles
platform-specific. In an unflattened layout, however, such as used by
default when using the GNUstep layout (as opposed to the FHS layout
that we are constrained to use in Fedora), fat binaries are possible:
binaries are stored under a directory specifying their platform.
for instance:
Hello.app
\--- i386
| \--- hello
\--- x86_64
\--- hello
This seems more desirable, in that it will allow an unmodified
'openapp' launcher to work on multilib systems: the default
application path is /usr/lib/GNUstep/Applications, regardless of
whether %{_libdir} is /usr/lib or /usr/lib64.
Please note that the unflattened layout is not just for different
archs, but even different compilers/libcombos. In a flattened world
one can only support one combo which for example will make
opengroupware conflict with other GNUstep apps.
At least this is my understanding, I don't know how Debian has solved
this, or even if opengroupware is part of Debian, so perhaps they
haven't seen the issue, yet.
The problem, right now, is that GNUstep tools are currently
installed
in /usr/bin/<arch>. Which conflicts with util-linux-ng, where
/usr/bin/<arch> is an executable wrapper around 'setarch <arch>'.
What if we simply crop off the <arch> from the path? Would that make
us fully FHS compliant again?
We would need to settle on our GNUstep layout, before the rest of
GNUstep can be packaged. The main options right now seem to be:
- FHS, flattened (like Debian). We would need to override GNUstep-make
to install under %{_libdir} rather than %{_prefix}/lib. It will
require a customized openapp to handle multilib systems
- FHS, unflattened (like our current gnustep-make). Works well with
multilib. We need to decide where to put GNUstep tools: Axel suggests
/usr/bin/GNUstep/<arch>.
Actually I suggested putting them under %{_libexecdir} with
symlinks/wrappers back to %{_bindir}. I don't think that a
subdirectory under %{_bindir} is really in FHS/Fedora spirit.
But now I think maybe we need to place them directly under %{_bindir}
and let rpm deal with the different archs as it does for all other
%{_bindir} mixing of subarchs with colors etc.
Base libraries currently go in /usr/lib/<arch>, and are
probably
fine there.
Shouldn't this at least go beneath %{_libdir} instead of /usr/lib?
Moving them to /usr/lib/GNUstep/<arch> might cause confusion as
the
higher-level frameworks are installed there.
- Pure GNUstep layout. Everything goes in /usr/GNUstep
Thanks for the writeup and if smeone is interested: Some discussion in
context of a bug report happened here:
https://bugzilla.redhat.com/show_bug.cgi?id=437551
I think Fedora's typical way of dealing with this is the following:
o multiarch/multilib binaries are not supported, e.g. all other
instances either hide non consumer binaries under %{_libdir}, or
allow x86_64 to overwrite less colorful cousins like i386.
o libraries need to be placed under %{_libdir}.
Thoughts? Once we come up with a consensus I'll probably start a
page on the Wiki. Anyone interested in joining a GNUstep SIG?
I think it is important for many GNUstep app builders to voice in
their experiences with the GNUstep build procedure and see how we can
make sure the layout we will be "setting in stone" by approval by the
FPC will be pleasing all.
A wiki page will be great as we can even ask non Fedorians like the
opengroupware people to have a look and see whether it would fit their
software's need.
--
Axel.Thimm at
ATrpms.net