public inbox for rhug-rhats@sourceware.org
 help / color / mirror / Atom feed
* RPM notes
@ 2002-03-03  0:19 Anthony Green
  2002-03-04 13:00 ` Tom Tromey
  0 siblings, 1 reply; 3+ messages in thread
From: Anthony Green @ 2002-03-03  0:19 UTC (permalink / raw)
  To: rhug-rhats

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





^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RPM notes
  2002-03-03  0:19 RPM notes Anthony Green
@ 2002-03-04 13:00 ` Tom Tromey
  2002-03-04 13:25   ` Anthony Green
  0 siblings, 1 reply; 3+ messages in thread
From: Tom Tromey @ 2002-03-04 13:00 UTC (permalink / raw)
  To: Anthony Green; +Cc: rhug-rhats

>>>>> "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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RPM notes
  2002-03-04 13:00 ` Tom Tromey
@ 2002-03-04 13:25   ` Anthony Green
  0 siblings, 0 replies; 3+ messages in thread
From: Anthony Green @ 2002-03-04 13:25 UTC (permalink / raw)
  To: tromey; +Cc: rhug-rhats

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-03-04 21:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-03  0:19 RPM notes Anthony Green
2002-03-04 13:00 ` Tom Tromey
2002-03-04 13:25   ` Anthony Green

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).