Gary Benson writes: > Andrew Haley wrote: > > Gary Benson writes: > > > Andrew Haley wrote: > > > > Gary Benson writes: > > > > > 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? > > > > It will be invoked from the specfile, but by either > > > > a. Going to some java dir and running make, or > > b. Running some VM-agnostic script that does a. > > > > That way, should there ever be some other VM that does > > precompilation, we need only to add a make rule for whatever it > > needs. > > Ok. FWIW I perfer B, but it's really something for JPackage not > Fedora to decide. As long as Fedora rpms can continue to call > 'rebuild-gcj-db' or 'gcj-dbtool --rebuild' until JPackage figure > out what they're doing then that's fine. Well, OK: I don't mind. Going through every RPM changing "rebuild-gcj-db" to "gcj-dbtool --rebuild" and then changing it again some time in the future sounds like a PITA to me ... but then I won't be doing it! Andrew.
