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