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
