Re: State of the 'Step

[Nicola Pero]

> what we need for all the other
> GNUstep applications is that converter from the GNUstep make file to
> package descriptors and this shouldn't be to hard.


From past experiences, I'm not sure a "converter" would help that  
much ;-)

IMO packaging a standard GNUstep application (say, Gorm) is easy to  
the point that any
attempt to automate it makes it more difficult! ;-)

For example, gnustep-make supports building RPMs out of the box using  
information you
type in some special gnustep-make variables in your GNUmakefile.   
Nobody uses it
presumably because you have to read and understand how it works.  If  
you're an RPM
packager it can be of an equivalent difficulty to just write the RPM  
spec file (after all, you
have to type in the same information - package name, title, copyright,  
description, etc) but
writing the RPM spec file directly is better as you have total control  
of the packaging.  And
there is massive, extensive documentation on writing RPM spec files,  
with millions of
examples and discussions. ;-)

Btw, GNUstep stuff used to be difficult to package because we didn't  
support some "standard"
options that packagers expect.  For example, a few years ago 'make  
DESTDIR=/tmp/install'
would not work ... but now it does :-)

Please check

 core/make/README.Packaging

for information on packaging GNUstep and GNUstep applications.  Let me  
know if anything is missing or needs
improvement.  Once you package gnustep-make and gnustep-base (which  
are the relatively hard ones) everything
else should be really simple/standard to package.

So I'm not sure that there is much to do in terms of automation (but  
feel free to suggest).  What we really need
are packagers and package repositories - and exciting end-user  
products to package of course :-D

Thanks