Re: GNUstep download section

[Nicola Pero]

> > How about some debs in addition to rpms? Or is no-one using
> > Debian here? 
> >
> I do.
>

I do at home.

 
> > There is someone maintaining the Debian packages
> > of GNUstep, I'd have to look up the name. 
> >
> 
> This used to be Matthias Klose <doko@debian.org> but he orphaned the
> GNUstep packages after offering them for adoption.  Unfortunately
> there was nobody either interested or capable of taking them over.
> Although being already a Debian maintainer myself (minor though) i
> didn't feel capable and dedicated enough to take them over.  I tried
> building the Debian GNUstep packages myself before and had a hard time
> with it.  GNUstep is far too complicated to build for my humble
> abilities.  Being more a user than a developer of free software,
> GNUstep just doesn't fill any software need for me.  Sorry folks, but
> why should a non-developer user want to run GNUstep anyway?

I don't have the time required to build regularly the binary packages of
all the libraries - thus I couldn't take the responsibility of becoming
the debian maintainer myself - but I have a debian at home and I can
certainly help with the debian scripts anyone willing to take over.

One thing to notice is that we are moving to a simpler organization of our
packages - we will not any longer have one big giant core package but
rather 4 different `little' independent packages - gnustep-make,
gnustep-base, gnustep-gui, gnustep-xgps.

These packages remain strictly related - because when you configure
gnustep-make, you are already configuring eg the gui libraries to use.

But maintaining the big core package takes much time and is complicated -
because when eg gnustep-gui is compiled, you can't assume that
gnustep-make and gnustep-base are already installed in place, which makes
things more complicated.  Breaking the system into pieces which can be
configured, compiled and installed independently makes it easier to
understand, maintain, debug - so we are going that way.

I think that the debian scripts can also be simplified a lot by this
rearrangement.  We will have a /debian subdir in each of gnustep-make,
gnustep-base, gnustep-gui and gnustep-xgps (gnustep-xpds).  Each of these
subdirs should be much simpler than the actual big /debian subdir in core.

Neverthless, the packages would need to be created in sync one after the
other, because eg in a certain sense part of the gui configuration is done
in gnustep-make.

Unless - unless - digression

<-->

Unless - a solution I personally like - we attempt yet a further
simplification, by decoupling completely the packages - we could have in
common.make:

-include base.make
-include gui.make
-include xgps.make
-include xdps.make

(the `-' will include them only if found, and don't complain if not).  
And then, we create eg `base.make' when we configure the base library (for
libxml, etc); and then install this makefile when the base library is
installed.  This base.make would add the flags needed for the base library
- such as -lxml, -lopenssl or whatever.  In this way, all checks for
libraries needed by the base library would be moved inside the base
library; similarly for the gui/xgps/xdps libraries; and the make package
would be left clean - probably with just a check for objective-c threading
flags.

[When we compile gnustep-base itself, we simply include directly the local
copy of base.make in the GNUmakefile.  To avoid an old copy of base.make
from /usr/GNUstep/System/Makefiles to be used when compiling the base
library itself, we can use a makefile variable to prevent an installed
base.make to be included from common.make when building the base library
itself.]

This would mean that:

 * People can safely configure/compile/install gnustep-make, gnustep-base,
   gnustep-gui and gnustep-xgps completely independently <of course, you 
   need an installed gnustep-make to compile gnustep-base, and you need
   an installed gnustep-base to compile gnustep-gui and gnustep-xgps>.  

   For example,
   if you install make and base without openssl and then decide you need
   it, install openssl, then you wouldn't need to recompile the make
   package but only the base one.  For graphic libraries it gets more
   important - if you install libwraster you wouldn't need to
   reconfigure/recompile/reinstall everything from scratch, but 
   only the gui/backend libraries.

 * The same for the RPM packages - and for the future DEB packages.

I think this would simplify a lot the RPM packaging and remove all the
difficult inter-dependencies between the RPM packages.

In particular, I think this would help having gnustep-make and
gnustep-base shipped with distributions, since they no longer depend on
other stuff such as the graphic libraries. <not that gnustep-make depends
on graphic libraries now, but once you have configured gnustep-make for a
certain set of graphic libraries you can't change it later on, which means
you can't change your gnustep-gui without changing in sync your
gnustep-make>

Basically - this - plugging in makefiles adding the correct flags when the
libraries are configured and installed - just seems a better design to me.

<-->

Actually, each of the gnustep-make, gnustep-base, gnustep-gui and
gnustep-xgps packages should be quite a standard package - without
complicated scripts needed - just a standard debian package - no
particular tweaking should be needed as far as I know.  

You probably want to add `. /usr/GNUstep/System/Makefiles/GNUstep.sh'
somewhere in /etc/ when gnustep-make is installed, and the two gdomap
lines into /etc/services when gnustep-base is installed.  That's all the
tweaking you need - the rest should be just a standard ./configure, make,
make install.  The only thing you might need to know is that to have `make
install' install into the debian/tmp directory, you need to use

INSTALL_ROOT_DIR=tmp GNUSTEP_INSTALLATION_DIR=tmp${GNUSTEP_SYSTEM_ROOT} \
                 make install

As you see, I am favourable to simplifying the debian scripts quite
heavily.

It would also be very nice at this point to build in debian package
support directly into the make package - a work perhaps to be done.