[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.
- GNUstep download section, Philippe C.D. Robert, 2001/01/24
- Re: GNUstep download section,
Nicola Pero <=
- Message not available