On the central db idea (as opposed to having each application having their own db), what happens on a partial disk failure, and e2fsck can't recover inodes that belong to the db? Reinstall all gcj built rpms? How would the user know what to do in that scenario? Do we keep a gzipped backup tucked away somewhere? Also, where would you put it? I imagine it would have to go somewhere on root say /usr/lib? If you put it, I dunno, in /var or somewhere like that, a mount failure would render all gcj apps back to fall back to interpretated. Just two questions that quickly occurred to me. The db almost sounds like it is going to become something akin to a registry like Windows has; I'm not saying that is a bad thing, but a single bad inode can spoil the party. ;) Regards Phil On Fri, 2005-03-11 at 10:49 -0700, Tom Tromey wrote: > FYI, I checked in a patch to gcc that sets the default database for > gij. Once this is put in the gcc RPM, you won't need to set the .db > on the gij command line. > > You can use "gcj-dbtool -p" in your spec file to get the name of the > default .db. > > > Jakub, libgcj will build and install a default .db. However, I'm not > sure we really want to have this file owned by the gcc RPM. It is > going to be modified by other RPMs as they are installed... what is > the usual thing to do in this situation? > > Tom > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
