[fedora-java] New file layout for nativified rpms

Gary Benson gbenson at redhat.com
Tue Jul 5 14:41:12 UTC 2005


Hi all,

The way bc-compiled rpms are made is currently time-consuming and
fiddly, and all too easy to make mistakes.  I'm writing a script to
automate this, but there's a number of changes to the filesystem
layout I'd like to introduce at the same time, partly out of necessity
and partly for future-proofing.

Currently, bc-compiled rpms have solibs in /usr/lib, one per jarfile,
and class mappings in /usr/lib/gcj-4.0.0/classmap.db.d, one per binary
rpm.  For instance, ant has these two jarfiles:

  /usr/share/java/ant-1.6.2.jar
  /usr/share/java/ant-launcher-1.6.2.jar

so it has these native files:
  
  /usr/lib/gcj-4.0.0/classmap.db.d/ant-1.6.2.db
  /usr/lib/libant-1.6.2.jar.so
  /usr/lib/libant-launcher-1.6.2.jar.so

Fully-automatic compilation will require one mapping database per
jarfile, and I'd like to stick all the solibs and databases in
package-specific databases under /usr/lib/gcj, so to continue the
example ant would have:

  /usr/lib/gcj/ant/libant-1.6.2.jar.db
  /usr/lib/gcj/ant/libant-1.6.2.jar.so
  /usr/lib/gcj/ant/libant-launcher-1.6.2.jar.db
  /usr/lib/gcj/ant/libant-launcher-1.6.2.jar.so

My reason for moving from /usr/lib/gcj-4.0.0/classmap.db.d as the
mappings directory is that this name will of course change when gcj
is upgraded -- I don't wish to rebuild my ninety-plus rpms every time
gcj bumps unless I actually have to.  We can make rebuild-gcj-db pick
up files from both the old and new directories until all rpms have
been rebuilt.

My reason for moving the solibs into this directory is simply because
then nativified rpms need only one line in their %files section to
pick up the native binaries.

Can anyone see any problems with this layout?

Cheers,
Gary




More information about the fedora-devel-java-list mailing list