discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep download section


From: Nicola Pero
Subject: Re: GNUstep download section
Date: Wed, 24 Jan 2001 12:05:56 +0000 (GMT)

Hi Philippe,

the RPM framework is starting to be operative but it's not yet the moment
to make announcements :-)

What we have now - immediately useful - is an RPM for shared libobjc.  
You just install the RPM before downloading GNUstep sources, then when you
configure GNUstep it will find your libobjc and all will work fine.  
Constrain - you need to configure GNUstep to go into /usr/GNUstep for this
to work, since the libobjc RPM installs it there. (ie, type ./configure
--prefix=/usr/GNUstep when configuring the make package).

\..Quick update about RPM support../

the RPM support in gnustep make has been written and rewritten two or
three times now - it should be working now and reasonably easy and usable.

But - packaging the whole core libraries into RPMs is still underway <the
links on the download page points to empty rpms>.

I have packaged into RPMs all the core non-graphical packages -
gnustep-make, gnustep-base, gnustep-base-debug, gnustep-guile,
gnustep-guile-debug, gnustep-tests, gnustep-java, gnustep-java-debug.

I have built i386 binary RPMs of all this stuff, and installed the RPMs
from scratch in my machine at work - they work.

But yep - you guess - the graphical libraries are not done - and I have
not given it a serious think about how to do - the problem being - quite
trivially - that gnustep-gui/gnustep-xgps will depend on libwraster >= 2.0
- and I don't have an RPM for redhat 6.2 which can provide me with that
library.  The problem is then that gnustep-make will configure itself for
a certain libwraster I think - so we can't distribute gnustep-make binary
rpms until the problem with libwraster is somewhat solved - but I'm not
sure about all this since I had no time to look at packaging the gui stuff
seriously.

Adam is now out - when he's back, we'll probably discuss/fix these
problems and he will really ship the real rpms.

About packaging other stuff into RPMs, this should be nearly trivial now.
Basically, here is an example for a package called `hiho': you need to add
to your top level GNUmakefile something like

PACKAGE_NAME = hiho
VERSION = 1.3.2

then, you add a file called `hiho.spec.in' in the topdir, something like
the following:

Release:        1
Source:         ftp://ftp.hiho.org/%{gs_name}-%{gs_version}.tar.gz
Copyright:      GPL
Group:          Development/Tools
Summary:        Hiho Tool
Packager:       Hiho ohih <ohih@hiho.org>
Vendor:         Hiho Project
URL:            http://www.hiho.org

%description
Hiho is a great tool for managing hihos.

Then, you become root, and type:

export RPM_TOPDIR=/usr/src/redhat
make rpm

<`/usr/src/redhat' is appropriate for RedHat - change it for your
distribution>.  

The make package will then do everything which is needed, and serve to you
your full spec file into /usr/src/redhat/SPEC/, your source RPM into
/usr/src/redhat/SOURCES/, your binary RPM into /usr/src/redhat/RPMS/i386/ 
<or xx/RPMS/ppc/ or whatever>.

One problem is that these binary RPMs will very likely contain
dependencies upon gnustep-base and possibly gnustep-gui and gnustep-xgps,
so it's not so much useful to create them now since we are not
distributing binary RPMs for gnustep-base, gnustep-gui etc yet.

Anyway - for testing purposes and/or preparing to when core libraries will
be shipped packaged I encourage anyone to try it out.

Deb support is planned too - but I don't have time to implement it right
now.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]