Andrew Haley wrote: > Gary Benson writes: > > Andrew Haley wrote: > > > Gary Benson writes: > > > > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_ > > > > alternatives, though not between JVMs: they're shared > > > > between versions of java-1.4.2-gcj*-compat. Tom > > > > Fitzsimmons wants them not to be alternatives, but to be > > > > in gcc subpackages (libgcj for r-g-d, and gcc-java for > > > > a-c-r). Almost incidentally, Tom pointed out that > > > > rebuild-gcj-db is so small its functionality could easily > > > > be incorporated in gcj-dbtool. > > > > > > Right. No argument there. I have no disagreement with any of > > > this. Making gcj-dbtool do the right thing is easy, and I'll do > > > it. > > > > Oh, ok, cool. In that case, you should know that you only need to > > scan /usr/lib/gcj. rebuild-gcj-db also scans $dblocation (aka > > /usr/lib/gcj-x.y.z/classmap.db.d) but that was just a workaround > > for FC4 and can be removed. > > OK. Oh, and something else. Even if we switch new rpms over to do something like 'gcj-dbtool --rebuild' we must retain something at /usr/bin/rebuild-gcj-db or it will become impossible to upgrade or uninstall the FC4 packages. My preference would be to have /usr/bin/rebuild-gcj-db a symbolic link to gcj-dbtool and have gcj-dbtool check its argv[0] (if that's possible under Java). Also note that while FC5 and the newest FC4 packages call rebuild-gcj-db with no arguments, the majority of FC4 packages will call 'rebuild-gcj-db /usr/lib' or 'rebuild-gcj-db /usr/lib64'. Any replacement must not choke on this. Cheers, Gary
