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. > > 2) On the other hand, Fernando wants the two scripts to remain > > alternatives, but shared between all JVMs (not just GCJ ones). > > My opinion is that something like this would be a good idea, > > but that acquiring the GCJ-specific command names for it is > > the wrong thing to do (not least because GCJ's database should > > be rebuilt whenever an rpm with GCJ-precompiled stuff is > > installed regardless of what JVM alternative is in force). > > This is the issue that I am addressing. > > My suggestion solves this problem: > > > GCJ's database should be rebuilt whenever an rpm with > > GCJ-precompiled stuff is installed regardless of what JVM > > alternative is in force > > ... without penalizing users who aren't installing gcj packages. It > also abstracts away from the RPM specfiles the nitpicky gcj details. > This is better than having "gcj-dbtool --rebuild" or its equivalent > in each specfile. When will it be invoked if not in every specfile? Cheers, Gary
