Gary Benson writes:
Andrew Haley wrote:
David Walluck writes:
I don't know how I feel about the Makefile idea. In any case, it should never require user intervention. What besides sendmail is using this method anyhow? IMO, `make' should be touched by packagers only, certainly not by end users, and not even by system admins.
They won't need to. The question here is how we fix our existing scripts so that they don't do unnecessary work. If we do that, then they can be called unconditionally. make is the right answer here, because it's a tool that already knows how to do the dependency analysis that's needed.
All it has to do is read every .db file under /usr/lib/gcj and write what it finds to a .db file in /var/lib/gcj. Where's the dependency analysis in that?
We can already do that.
My suggestion was a way to only do that when we know we really have to. So, if you install a RPM that doesn't add or remove any .db files, nothing gets rebuilt because make doesn't see any changed dependencies.
This completely solves the problem of
That aside, having the database rebuilding as an alternative (so possibly a no-op) would also cause problems. Imagine this:
- User has GCJ as their JVM.
- a) User installs some Fedora packages. b) GCJ database is rebuilt into a consistent state.
- User switches to some other JVM.
- a) User installs some more Fedora packages. b) GCJ database is not rebuilt.
- User switches to GCJ as their JVM.
The user has ended up with a broken database. His applications will be slower, and in some (admittedly broken) cases will suddenly start to fail.
Rather than being an alternative, the rebuild command would need to rebuild all databases that could be installed on the system. This could be done by for example having all JVMs drop scripts in some database, and having 'aot-compile --rebuild' or whatever call them all in turn.
which was clipped from the mail.
Don't make database rebuilding an alternative. Use make.
Andrew.