RPM notes

RPM notes

[Anthony Green]

I started making RPMs today, and thought I'd share some random notes for
the record...

* I've created nice RPM configury for 4 of the packages: xerces,
gnu.readline, rhino, and jakarta-oro.  They're very easy to create once
you have the pattern down.

* We currently create two kinds of RPMs..  rhug-PACKAGE-VERSION and
rhug-PACKAGE-VERSION-devel.  

* The non-devel version currently contains executables, .so files and
.jar files.  You could argue that the .jar file should go into the
-devel package, but maybe the right thing is to stick them into noarch
packages and make -devel depend on those.

* Normally non-devel library RPMs contain *.so.* , and not *.so files
(which go in -devel).  However, our classloader currently looks for *.so
files, so we must include those in the non-devel package.  Should we
change the classloader?  How would it know which version to load?

* I'm installing the .jar files in $prefix/share/java (but no links to
an ext directory yet -- let's wait for the tools to catch up).

* The packages know whether or not they're being built in a unified
tree, or separately, and set the classpath and -L options appropriately
at configure time.

* I submitted a patch to rpm-list@redhat.com to add support for GCJFLAGS
in RPM.  RPM already sets CFLAGS, CXXFLAGS, and FFLAGS appropriately. 
GCJFLAGS is an obvious addition, but it's not critical yet.

* I haven't dealt with docs yet (.html files).  Most of them will live
in the -devel packages.

* Much of the specs files should be generated from the info.rml files.

* Creating RPMs is easy.  Run "make dist" in the package directory to
create rhug-PACKAGE-VERSION.tar.gz, then run "rpm -ta
rhug-PACKAGE-VERSION.tar.gz".  It will extract the spec file from the
tar ball and take care of everything.

* Obviously there are no RPMs yet for the latest gcj libs which are
needed to run these things.  You have to force the install like so...
"rpm -hiv --nodeps rhug-gnu_readline-0.6-1.i386.rpm" and just put
libgcj.so and friends in your LD_LIBRARY_PATH.

That's it for now.

AG

Re: RPM notes

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

Anthony> * We currently create two kinds of RPMs..
Anthony> rhug-PACKAGE-VERSION and rhug-PACKAGE-VERSION-devel.

I think it would make sense to generate all the RPMs for a given
package at once: the ordinary bytecode RPM, plus the corresponding
devel package, plus both rhug packages.  This might mean coordinating
with the vendors in some way.  What do you think of that?  The benefit
is version consistency, and also single ownership of the .jar file.

Anthony> * Normally non-devel library RPMs contain *.so.* , and not
Anthony> *.so files (which go in -devel).  However, our classloader
Anthony> currently looks for *.so files, so we must include those in
Anthony> the non-devel package.  Should we change the classloader?
Anthony> How would it know which version to load?

Actually the problem is lower than the classloader; we use libltdl to
load the libraries.  Whatever it decides is what happens.

This is great work, btw.

Tom

Re: RPM notes

[Anthony Green]

On Mon, 2002-03-04 at 13:28, Tom Tromey wrote:
> I think it would make sense to generate all the RPMs for a given
> package at once: the ordinary bytecode RPM, plus the corresponding
> devel package, plus both rhug packages.  

I only envision 3 packages:
* The native runtime binary package
* The noarch package with .jar and property files.
* The devel package with static libs, headers and API documentation.

What is the fourth?

> This might mean coordinating
> with the vendors in some way.  What do you think of that?  The benefit
> is version consistency, and also single ownership of the .jar file.

In a perfect world, yes... however I suspect that this will be difficult
to get going.  For instance, the RPMs I've seen for many of these
packages are already maintained by 3rd parties.  The RPM maintainers
would have to be sufficiently motivated to maintain dual build systems
(ANT, which is almost the universal build tool of choice for Java, and
the rhug mechanism -- or we somehow figure out how to build binaries
from ANT (I am skeptical, or we figure out an automated ANT -> autotool
converter).  We have a number of local hacks to work around (1) compiler
bugs and (2) different runtime features and (3) different runtime
semantics.  These would have to be maintained somehow as well.  We can
try to push as many upstream as possible.

> This is great work, btw.

Thanks!  I got many more packages cleaned up yesterday.  Probably more
than half are done now.

AG